HiGHS LP file reader should return an error when it encounters constraints that are not linear

[LocatedInSpace]

The attached model arrives at an optimal value of 7 for HiGHS with default options (I've tried changing various options blindly, to no avail in terms of changing result), whereas the expected optimal value of 14 is achieved by CPLEX with no issue.

If you add another constraint akin to test: t10178p0 = 1 then HiGHS now reports the model as Infeasible whereas CPLEX still gives the expected correct outcome with t10178p0 = 1 & t9717p0 = 1. It has no effect whether you run HiGHS with parallel off or on, nor presolve on or off - they all arrive at either 7 or Infeasible.

If, in the infeasible case, run with write_iis_model_file it just results in the below file - so not much help.

\ File written by HiGHS .lp file handler
min
 obj: 
st
bounds
end

This problem is present in both 1.13.1 and 1.13.0 on Windows.

lpmodelandlogs.zip

[jajhall]

The problem is due to having lines such as

score_group0_t9717p0_1: winS_0 - S_t9717p0 GS_t9717p0 >= 0

since they involve a product of variables. Somehow HiGHS interprets them as linear constraints, reducing the optimal objective value to 7.

If they are commented out (see lpmodel-lp.lp.txt) HiGHS gives the objective of 14.

I guess that CPLEX ignores these lines - rather than interpreting them as quadratic constraints and solving the MIQP

Did you mean to formulate a MIQP?

The HiGHS LP file reader should return an error when it encounters constraints that are not linear.

[LocatedInSpace]

Seemingly the restraints are respected in CPLEX when I change scores to influence decision - it might be automatically unfurling them to something akin to score_group0_t9717p0_1: winS_0 - S_t9717p0 - 104 GS_t9717p0 >= -104 through the other constraint? I am using HiGHS through the executable, and it is not reporting anything about errors with the constraints, but when I change the logic to use the unfurled example above it does indeed report the correct objective value.
So.. seemingly a bug in the parser/cli that doesn't throw an error for wrongly parsed line then?

[jajhall]

Quite what CPLEX might be doing is anyone's guess, but I don't see how you can deduce score_group0_t9717p0_1: winS_0 - S_t9717p0 - 104 GS_t9717p0 >= -104, but clearly you can interpret this in terms of your model.

The original file is not valid, though, as another major commercial solver returns an error when it encounters the line

score_group0_t9717p0_1: winS_0 - S_t9717p0 GS_t9717p0 >= 0

As you say, the issue with HiGHS is that it doesn't return an error when it encounters this line - hence my change in the issue title

[odow]

Here's JuMP for comparison sake:

julia> using JuMP

julia> read_from_file("/Users/odow/Downloads/lpmodelandlogs/lpmodel.lp")
ERROR: Error parsing LP file on line 72:
e_group0_t9717p0_1: winS_0 - S_t9717p0 GS_t9717p0 >= 0
                                       ^
Got an identifier with value `GS_t9717p0`. We expected this to be an inequality like `>=`, `<=`, or `==`.
Stacktrace:

[jajhall]

Exactly, @odow that's the sort of contradiction I'd expect the HiGHS LP file reader to identify.

[jajhall]

Here's a reduced instance

Maximize
obj: w + 7 x - y
Subject To
score_y1: w - y z >= 0
Bounds
95 <= z <= 104
Binary
w x
End

[odow]

Minimal examples are probably

minimize
obj: x y
End

and

minimize
obj: x + y
subject to
c: x y <= 0
End