Re: Same model different results

[Chris]

If I call computeIIS() for the infeasible model, I receive the complete model.

[zinc...@gurobi.com]

Hello Chris:  it is very likely that your model has numerical issues, which makes it "border-line" feasible, and depending on the presolve trajectory the solver reaches different conclusions.  Note also that in the second case you are posting, Gurobi uses a warm start to get to a different resolve point, see the log.

You may want to try to experiment with different tolerance settings for the solver, e.g., 

FeasibilityTol
IntFeasTol

https://www.gurobi.com/documentation/8.1/refman/parameters.html, to get a more consistent behaviour, i.e., try to tighten these tolerances.

With regards to your second posting re computeIIS(), this is perfect;y possible -- if you are seeing a complete model returned, this means that by dropping any single constraint the feasibility should be restored.  However, I would first go after the numeric issues as above.

Let me know if this helps,

[Michael Winkler]

Hi Chris,

Gurobi is deterministic, i.e., the same model with the same parameters on the same machine produces the same solution path. Also, just using the same model (independent of the machine or changed parameters) should produce the same optimal solution value. Two models are regarded as the same when also the column, row and coefficient order is equal.

Using a MIP start (as seen in your second screen shot) might change the path but presolve should stay the same (if you did not change any parameters). So there must be something different between your attached lp file and the model (or parameters) you solve in your second screenshot. Note that a change in parameters should not influence the final result but might change the solution path. Only numerical issues or bugs can be the reason for this.

I would suggest that in your long iteration that leads to an infeasible result you write out the exact model file (best in MPS format) and also the parameters (prm file, in python model.write("infeas.prm"), maybe also the MIP start with model.write("infeas.mst")).

You should be able to reproduce the infeasibility with this MPS and PRM file.

Best,

Michael

[Chris]

Sorry, I didn't see the answers and deleted in order to make a re-post cause I thought I'd have to improve the question to receive answers. Here is the question again.

I solve the exact same model and receive different results.

Solving it within the interactive optimizer I get:

gurobi> m = read('./068_SP_nopro.lp')
Read LP format model from file ./068_SP_nopro.lp
Reading time = 0.01 seconds
: 650 rows, 327 columns, 1936 nonzeros
gurobi> m.optimize()
Optimize a model with 650 rows, 327 columns and 1936 nonzeros
Variable types: 1 continuous, 326 integer (144 binary)
Coefficient statistics:
  Matrix range     [1e+00, 6e+03]
  Objective range  [1e+04, 1e+04]
  Bounds range     [1e+00, 2e+01]
  RHS range        [1e+00, 1e+04]
Presolve removed 104 rows and 27 columns
Presolve time: 0.02s
Presolved: 546 rows, 300 columns, 1602 nonzeros
Variable types: 0 continuous, 300 integer (128 binary)
Found heuristic solution: objective 10000.100000

Explored 0 nodes (0 simplex iterations) in 0.02 seconds
Thread count was 4 (of 4 available processors)

Solution count 1: 10000.1

Optimal solution found (tolerance 1.00e-04)
Best objective 1.000010000000e+04, best bound 1.000010000000e+04, gap 0.0000%
gurobi>

Solving it within a long running procedure where the same model is solved with many different objectives yields:

Optimize a model with 650 rows, 327 columns and 1936 nonzeros
Variable types: 1 continuous, 326 integer (144 binary)
Coefficient statistics:
  Matrix range     [1e+00, 6e+03]
  Objective range  [1e+04, 1e+04]
  Bounds range     [1e+00, 2e+01]
  RHS range        [1e+00, 1e+04]

MIP start did not produce a new incumbent solution

Presolve removed 20 rows and 38 columns
Presolve time: 0.00s

Explored 0 nodes (0 simplex iterations) in 0.00 seconds
Thread count was 1 (of 4 available processors)

Solution count 0

Model is infeasible
Best objective -, best bound -, gap -

When I call computeIIS() and write the ilp, I receive all of the model.

I think there should be a section in the documentation that highlights the effects of solving models over and over again because it seems that it influences the optimization somehow.

Thanks for replying!

[Michael Winkler]

Yuriys and my answers are still something you should test.

Best,

Michael

[Chris]

Hi Michael,

thanks a lot for you help!

In the model which becomes infeasible I have

 set(GRB.IntParam.PrePasses, 1);
 set(GRB.DoubleParam.Cutoff, 0);

I removed the PrePasses-setting, but I still can reproduce the problem.

I attached a model where the problem occurred in LP and MPS format and also the IIS and also "infeas.prm".

The exact same model was solved at an earlier time within the procedure and a solution was found then!
Furthermore, I can import the model and solve it with the interactive optimizer shell!

This seems buggy to me. My workaround at the moment is to discard the model and build it new and that works. Furthermore, I am working on a special purpose algorithm for the problem, which is anyway more appropriate. Nevertheless, it would be helpful to find a cure for this.

Best

Chris

[Chris]

I increased the

FeasibilityTol
IntFeasTol

from the default values to

    set(DoubleParam.FeasibilityTol, 10e-9);
    set(DoubleParam.IntFeasTol, 10e-8);

The same problem occurred.

[Michael Winkler]

Now it makes sense. Setting the CutoffBound means you are only interested in solutions not worse than the value you are setting. Since it is a minimization model and you set the cutoff bound to 0, you are only interested in finding solutions with an objective smaller than or equal to 0. Since the optimal solution without this parameter has a solution value of 10000.1 there is no solution which can fulfill your cutoff parameter; the remaining problem is infeasible.


Best,

Michael

[Chris]

Oh wow, I expected the status code to be CUTTOFF, but it totally makes sense to not continue to search for a feasible solution (to prove feasibility), if the dual bound is already worse than the the CUTOFF. How foolish of me.

Thank you Michael!