IIS "light"

[jajhall]

The irreducible infeasibility system (IIS) facility now detects infeasibility due to bounds on constraint activity values being incompatible with constraint bounds.

A kIisStrategyLight mode for the iis_strategy option has been introduced so that only infeasibility due to incompatible variable/constraint bounds and constraint activity values is checked for.

The LP corresponding to any known IIS is now formed and held as a data member of the HighsIis class.

Highs::checkIis has been added for unit testing and beta testing. It takes the IIS LP, checks that it's infeasible and then relaxes each finite variable/constraint bound in turn, and solves the corresponding LP, checking that the model status is HighsModelStatus::kOptimal or HighsModelStatus::kUnbounded. Since the IIS LP is so small, the cost of the check is trivial compared with finding an IIS, so maybe the checking should be done a priori.

[codecov]

Codecov Report

❌ Patch coverage is 84.09836% with 97 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.59%. Comparing base (bab3f9e) to head (c6a70c5).
⚠️ Report is 24 commits behind head on latest.

Files with missing lines	Patch %	Lines
highs/lp_data/HighsIis.cpp	80.69%	67 Missing ⚠️
highs/lp_data/HighsInterface.cpp	70.21%	14 Missing ⚠️
highs/lp_data/Highs.cpp	46.66%	8 Missing ⚠️
highs/interfaces/highs_c_api.cpp	89.65%	3 Missing ⚠️
highs/lp_data/HighsOptions.h	72.72%	3 Missing ⚠️
highs/Highs.h	0.00%	1 Missing ⚠️
highs/util/HighsSparseMatrix.cpp	87.50%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           latest    #2456      +/-   ##
==========================================
+ Coverage   79.57%   79.59%   +0.01%     
==========================================
  Files         346      346              
  Lines       85395    85838     +443     
==========================================
+ Hits        67955    68321     +366     
- Misses      17440    17517      +77     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[odow]

How would you see this being used from the C API?

Can we tie the original rows and columns to the rows and columns in the IIS?

JuMP wants to be able to call some sort of Highs_computeIIS(highs) method, and then check an enum of IN_CONFLICT, NOT_IN_CONFLICT, MAYBE_IN_CONFLICT for each variable, bound, and constraint row.

[odow]

We should have strong reasons to not follow the Gurobi API:

https://docs.gurobi.com/projects/optimizer/en/current/reference/c/solving.html#c.GRBcomputeIIS

[jajhall]

We should have strong reasons to not follow the Gurobi API:

https://docs.gurobi.com/projects/optimizer/en/current/reference/c/solving.html#c.GRBcomputeIIS

Can we tie the original rows and columns to the rows and columns in the IIS?

Thanks, I'll add this. I was working from the Xpress IIS API

JuMP wants to be able to call some sort of Highs_computeIIS(highs) method, and then check an enum of IN_CONFLICT, NOT_IN_CONFLICT, MAYBE_IN_CONFLICT for each variable, bound, and constraint row.

I'll add this. I assume that MAYBE_IN_CONFLICT is used when the IIS calculation has terminated prematurely.

The FORCE attribute is interesting. I won't add it yet, as the full IIS calculation is WIP, and I'm yet to identify precisely what needs to be completed/debugged/improved.

[jajhall]

an enum of IN_CONFLICT, NOT_IN_CONFLICT, MAYBE_IN_CONFLICT for each variable, bound, and constraint row.

Do you mean one enum for each variable and each constraint, or do you want to know whether a specific variable/constraint lower/upper bound has this status?

Corresponding to each variable/constraint in the IIS, there's a bound status to indicate whether just the lower, just the upper, or both bounds are finite in the IIS LP.

@odow, there are a few more IIS issues that it would be good to discuss at the next HiGHS-JuMP meeting

[odow]

What is the difference between _bound and _status? The _bound is free/lower/upper/boxed and the _status is in conflict/not in conflcit/maybe in conflict?

If we're returning only a subset of the rows and columns, the status would never be "not in conflict", so are both vectors needed?

Perhaps to answer my own question: if the IIS is not minimal, then there might be a "maybe in conflict" entry. If all are "in conflict" then the IIS is minimal.

[jajhall]

What is the difference between _bound and _status? The _bound is free/lower/upper/boxed and the _status is in conflict/not in conflcit/maybe in conflict?

Yes

If we're returning only a subset of the rows and columns, the status would never be "not in conflict", so are both vectors needed?

These vectors aren't needed at the moment, but if the IIS calculation is interrupted by timeout, say, then (as you guessed) the IIS is not minimal, so there might be a "maybe in conflict" entry. If all are "in conflict" then the IIS is minimal.

[jajhall]

• IIS LP is now tested in Highs::getIis, so Highs::checkIis has been removed
• Highs::writeIisModel can take a foo.mps, foo.lp or "" argument
• HighsIisnow has data members

1. std::vector<HighsInt> col_status_ and std::vector<HighsInt> row_status_ giving kIisStatusInConflict or kIisStatusNotInConflict for each column and row of the original LP
2. HighsModel model_ rather than HighsLp lp_
3. Highs::getIisLp() to return a const reference to Highs::iis_.model_.lp_, any incumbent IIS LP

Methods and docstrings have been added to the C API

[filipforro]

Hi, thanks for the work on this! Do you have any expectation when this will be available? We're interested in having the IIS available for use through the C API.

[jajhall]

Hi, thanks for the work on this! Do you have any expectation when this will be available? We're interested in having the IIS available for use through the C API.

I can't see a new release before mid-September, as we're doing a lot of urgent development work at the moment.

However, the necessary methods are already in the C API - and tested with our other C API tests.

[filipforro]

Thanks for the update!

However, the necessary methods are already in the C API - and tested with our other C API tests.

I was looking in the interfaces and have not seen the IIS methods exposed in the API, and saw them being added in this PR (2d0bb19).

[jajhall]

Thanks for the update!

However, the necessary methods are already in the C API - and tested with our other C API tests.

I was looking in the interfaces and have not seen the IIS methods exposed in the API, and saw them being added in this PR (2d0bb19).

This is because the "interfaces" you quote are in the master branch, and #2456 has not even been merged into latest.

[BenChampion]

Happened to notice a typo here: inconsistentyly

EDIT: sorry, did not see you already merged this