GLPK reports ABNORMAL instead of INFEASIBLE

[syxolk]

Hi, I'm using OR-Tools 7.2 (Python 3) with GLPK 4.65. When running the following code, I receive a result status of ABNORMAL instead of INFEASIBLE (as observed with Gurobi 8.1 and CBC):

from ortools.linear_solver import pywraplp

solver = pywraplp.Solver('test', pywraplp.Solver.GLPK_MIXED_INTEGER_PROGRAMMING)
solver.EnableOutput()
x = solver.IntVar(0, 10, "")
solver.Add(x >= 20)

result_status = solver.Solve()
print(result_status) # outputs: 4

GLPK output:

Scaling...
 A: min|aij| =  1.000e+00  max|aij| =  1.000e+00  ratio =  1.000e+00
Problem data seem to be well scaled
Constructing initial basis...
Size of triangular part is 1
GLPK Simplex Optimizer, v4.65
1 row, 1 column, 1 non-zero
Preprocessing...
PROBLEM HAS NO PRIMAL FEASIBLE SOLUTION

Is this expected behavior?

[lperron]

I do not trust glpk or CBC results.

So I would say yes.

Even gurobi and cplex can disagree. It comes with the technology.

Le lun. 29 juil. 2019 à 05:49, Hans notifications@github.com a écrit :

Hi, I'm using OR-Tools 7.2 (Python 3) with GLPK 4.65. When running the following code, I receive a result status of ABNORMAL instead of INFEASIBLE (as observed with Gurobi 8.1 and CBC):

from ortools.linear_solver import pywraplp

solver = pywraplp.Solver('test', pywraplp.Solver.GLPK_MIXED_INTEGER_PROGRAMMING) solver.EnableOutput() x = solver.IntVar(0, 10, "") solver.Add(x >= 20)

result_status = solver.Solve()print(result_status)

GLPK output:

Scaling... A: min|aij| = 1.000e+00 max|aij| = 1.000e+00 ratio = 1.000e+00 Problem data seem to be well scaled Constructing initial basis... Size of triangular part is 1 GLPK Simplex Optimizer, v4.65 1 row, 1 column, 1 non-zero Preprocessing... PROBLEM HAS NO PRIMAL FEASIBLE SOLUTION

Is this expected behavior?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/or-tools/issues/1459?email_source=notifications&email_token=ACUPL3PODAVADJ3NMBIH6FLQB3RPLA5CNFSM4IHSCSY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HCBFPLQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ACUPL3JH3HLOG7TKVRXZUKTQB3RPLANCNFSM4IHSCSYQ .

[syxolk]

Ok, I thought this a mapping problem of GLPK status codes to OR-Tools status codes.

[lperron]

Status code are very different across solvers. I believe GLOP returns ABNORMAL if the problem is proved infeasible during presolve, and INFEASIBLE is proved during search. Something like that.

Your code should check for both abnormal or infeasible. Laurent Perron | Operations Research | lperron@google.com | (33) 1 42 68 53 00

Le mar. 30 juil. 2019 à 11:30, Hans notifications@github.com a écrit :

Ok, I thought this a mapping problem of GLPK status codes to OR-Tools status codes.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/google/or-tools/issues/1459?email_source=notifications&email_token=ACUPL3MVRA2BO5THSYAIJJDQCCCC3A5CNFSM4IHSCSY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3E4AMI#issuecomment-516538417, or mute the thread https://github.com/notifications/unsubscribe-auth/ACUPL3KSJVERXTOIYQTUKX3QCCCC3ANCNFSM4IHSCSYQ .

[syxolk]

Your code should check for both abnormal or infeasible.

Thanks for the suggestion! I thought ABNORMAL is some kind of unknown state of the solver itself.

[syxolk]

Just for the record, I found some relevant information in the glpk_interface code:

https://github.com/google/or-tools/blob/b027e57e95e2f70d17c28d6f6319e57dcbbd46b2/ortools/linear_solver/glpk_interface.cc#L552-L556

This is probably what was happening in my minimal example, especially since it stops directly after "Preprocessing..."

[marianneke]

I do not trust glpk or CBC results. So I would say yes. Even gurobi and cplex can disagree. It comes with the technology. Le lun. 29 juil. 2019 à 05:49, Hans notifications@github.com a écrit :

Are there open source solvers you would trust?