The problem is also described here (https://github.com/henriquebecker91/GeneratorG2OPP) and the specific MPS is in the same repository (https://raw.githubusercontent.com/henriquebecker91/GeneratorG2OPP/main/gurobi_simplex_vs_barrier/G2OPP_s1_L20_W20_n16_i0135.mps).
I repeat the explanation given in the repository below:
The following command gives an unfeasible model in Gurobi 9.1.2.
gurobi_cl Method=2 Seed=1 Threads=1 G2OPP_s1_L20_W20_n16_i0135.mps
However, if you take out any of the parameters (either
Threads) then Gurobi finds a feasible solution.
I know the Gurobi is right when it gives a feasible solution, because I have generated the problem instances in a way that at least a single feasible solution exists.
The gurobi.log is also available and show this behaviour (I have run with the three parameters and with each combination of two parameters): https://github.com/henriquebecker91/GeneratorG2OPP/blob/main/gurobi_simplex_vs_barrier/gurobi.log
Is this a bug or expected behaviour?
Please sign in to leave a comment.