Since latest update, Highs returns "unable to read LP model" while the error should be "infeasible problem"

Question

Since latest update, Highs returns "unable to read LP model" while the error should be "infeasible problem"

Closed this issue 2 years ago · 16 comments

Hello,

As per issue title.

Reproducer:

Minimize
obj: x1
Subject To
c1: 1 x0 1 x1 = 1
Bounds
0 <= x1 <= 1
1.1 <= x2 <= 1
End

This now results in an (incorrect) LP-model reading error, while with the previous release, the error was that the problem is infeasible (correct), c.f. screenshot:

By the way, not sure the problem is with the JavaScript wrapper, because I see there was an update of Highs version.

Edit: I saw there were some changes in the parsing out HiGHS output as well (535a0d3), so, maybe one of these now incorrectly manage this infeasible problem.

Cheers,

Roman

Answer 1 · 2022-05-19T07:08:40.000Z

I'll look at this: there have been quite a few modifications to our .lp file reader in the past few weeks.

Answer 2 · 2022-05-19T07:47:15.000Z

HiGHS::readModel(filename) reads this problem, but correctly returns a warning value of 1 due to the inconsistent bounds.

The value of HighsStatus::kWarning was changed a while ago - before v1.1.1 was created on 27/9/21 - so it's nothing new

Answer 3 · 2022-05-19T07:47:47.000Z

Sorry: hit close issue, rather than comment!

Answer 4 · 2022-05-19T08:41:22.000Z

Thanks @jajhall , so, it means this is a side effect of a change in the JavaScript wrapper then.

Answer 5 · 2022-05-20T18:00:52.000Z

What does 1 x0 1 x1 = 1 mean? 1 x0 + 1 x1 = 1 or something more like a quadratic constraint a la [2 x0 x1]/2?

Answer 6 · 2022-05-20T18:08:54.000Z

Well spotted. I guess it's interpreted as x0+x1 as HiGHS can't handle quadratic constraints

Answer 7 · 2022-05-20T19:08:40.000Z

Yep, interpreted as x0 + x1 indeed.

Answer 8 · 2022-05-21T19:24:26.000Z

This is unrelated to changes in output parsing and happens already when loading the model; concretely, this happens because the C API function readModel returns a non-zero value (HighsStatus::kWarning as opposed to HighsStatus::kOk) where highs-js expects a 0 (cf. assert_ok). Removing this check yields a result whose Status is 'Infeasible'. So I guess the change in behavior comes from readModel changing its value from kOk to kWarning for this particular input.

Answer 9 · 2022-05-21T20:44:31.000Z

@fuglede , while I cannot comment more than this, my 2 cents if I may.

I interpret what @jajhall wrote as "no change in HiGHS output since Sep 2021".

I interpret what you wrote as "1) the problem is linked to HiGHS ouput, wrongly interpreted by high-js and 2) the problem is not linked to change in highs-js output parsing"

But then, why this sudden change of behaviour of high-js between highs-js 0.5.0 and 0.6.0?

Cheers,

Roman

Answer 10 · 2022-05-21T22:01:58.000Z

The "pretty" output hasn't changed since Sept 2021, but it's just possible that the warning return when inconsistent bounds are specified is post Sept 2021. This could cause "this sudden change of behaviour of high-js between highs-js 0.5.0 and 0.6.0?"

Answer 11 · 2022-05-22T08:18:00.000Z

Thanks @jajhall.

Would it makes sense that such changes of behaviour of HiGHS be tracked in release notes, so that when integrating a new HiGHS version in high-js, integrators are aware of these changes and can cross-ref any issue with them?

(And/or implementing regular/automated bump of HiGHS version to high-js, in the same spirit, to be able to kind of immediately detect changes upon integration of a new HiGHS version?)

Answer 12 · 2022-05-22T08:28:48.000Z

We are starting to develop release notes, but can't track things at this level of detail. The short answer in this case is that, as with any HiGHS call, you need to consider a warning return as well as error.

Answer 13 · 2022-05-22T11:26:37.000Z

I guess this recommendation is matching was is being done through #18, so, should be all good!

Answer 14 · 2022-05-22T12:24:43.000Z

What does 1 x0 1 x1 = 1 mean? 1 x0 + 1 x1 = 1 or something more like a quadratic constraint a la [2 x0 x1]/2?

By the way, Gurobi throws up the following error if it's given the .lp file with this line

Error reading LP format file ml.lp at line 5
Malformed term in expression
Neighboring tokens: " 1 x0 1 x1 = 1 Bounds 0 "

Error 10012: Unable to read file

Although HiGHS currently reads it, I'd rather throw an error since the file reader is assuming a "+" symbol (and hence a linear constraint) when a user might think that he's defined a quadratic constraint or forgotten to put in the "-" sign when he wanted x0 - x1 = 1

Answer 15 · 2022-05-22T18:24:13.000Z

Although HiGHS currently reads it, I'd rather throw an error

I agree; since whitespace is generally disregarded completely in the format, I think the correct parsing (but likely always unintentional) here would be 1 x01x1 = 1, cf. ERGO-Code/HiGHS#851. From a quick look, the changes in ERGO-Code/HiGHS#873 are not quite sufficient to cause it to throw an error here.

Answer 16 · 2022-05-22T19:03:45.000Z

Handling whitespace correctly in LP files is something that @feldmeier will work on, and we discussed spaces in variable names on Thursday. He's got other priorities, though.

I disagree about interpreting 1 x0 1 x1 = 1 as 1 x01x1 = 1, since Gurobi considers it as an error.