Presolve in Gurobi 10 vs Gurobi 9
Answered
Hello there,
I have been working with Gurobi 9.5.2 for a while and today I have decided to upgrade to Gurobi 10. To test the performance between both versions, I ran a MIQP model I have been working on each of them, I have appreciated that Gurobi 9.5.2 performs a better presolve process than Gurobi 10. I have not activate any presolve parameter, only the following parameters:
OutputFlag = 1
threads = 8
timelimit = 1800
MIPGap = 1e-4
MIPFocus = 0
On the one hand, Gurobi 10.0.0, the presolved model has 622 rows, 328 columns, 1282 nonzeros. On the other hand, Gurobi 9.5.2 has 481 rows, 281 columns, 1000 nonzeros. I attach the report of each model below.
My questions are: As the models are identical, why Gurobi 10.0.0 returns a bigger model than Gurobi 9.5.2? How can I fixed it?
Gurobi Optimizer version 9.5.2 build v9.5.2rc0 (linux64)
Optimize a model with 481 rows, 281 columns and 1000 nonzeros
Model has 29141 quadratic objective terms
Variable types: 241 continuous, 40 integer (40 binary)
Coefficient statistics:
Matrix range [1e+00, 1e+03]
Objective range [4e-02, 2e+02]
QObjective range [8e-06, 9e+10]
Bounds range [1e+00, 1e+00]
RHS range [1e+01, 1e+01]
Warning: Model contains large quadratic objective coefficient range
Consider reformulating model or setting NumericFocus parameter
to avoid numerical issues.
Loaded user MIP start with objective -314.741
Presolve time: 0.01s
Presolved: 481 rows, 281 columns, 1000 nonzeros
Presolved model has 29141 quadratic objective terms
Variable types: 241 continuous, 40 integer (40 binary)
Root relaxation: objective -3.428279e+02, 1249 iterations, 0.31 seconds (0.18 work units)
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 -342.82793 0 27 -314.74133 -342.82793 8.92% - 0s
0 0 -342.82793 0 27 -314.74133 -342.82793 8.92% - 0s
H 0 0 -316.87407 -342.82793 8.19% - 0s
0 2 -342.82793 0 26 -316.87407 -342.82793 8.19% - 0s
H 167 56 -317.62884 -342.53271 7.84% 8.1 1s
H 231 72 -317.71244 -342.53271 7.81% 8.2 2s
* 315 75 28 -317.71245 -338.72358 6.61% 7.8 2s
Explored 791 nodes (5962 simplex iterations) in 3.88 seconds (0.93 work units)
Solution count 3: -317.712 -316.874 -314.741
No other solutions better than -317.712
Optimal solution found (tolerance 1.00e-04)
Best objective -3.177124548952e+02, best bound -3.177124548952e+02, gap 0.0000%
Gurobi Optimizer version 10.0.0 build v10.0.0rc2 (linux64)
Optimize a model with 481 rows, 281 columns and 1000 nonzeros
Model has 29141 quadratic objective terms
Variable types: 241 continuous, 40 integer (40 binary)
Coefficient statistics:
Matrix range [1e+00, 1e+03]
Objective range [4e-02, 2e+02]
QObjective range [8e-06, 9e+10]
Bounds range [1e+00, 1e+00]
RHS range [1e+01, 1e+01]
Warning: Model contains large quadratic objective coefficient range
Consider reformulating model or setting NumericFocus parameter
to avoid numerical issues.
Loaded user MIP start with objective -314.741
Presolve time: 0.04s
Presolved: 622 rows, 328 columns, 1282 nonzeros
Presolved model has 29188 quadratic objective terms
Variable types: 288 continuous, 40 integer (40 binary)
Root relaxation: objective -3.428279e+02, 1392 iterations, 0.59 seconds (0.21 work units)
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 -342.82793 0 27 -314.74133 -342.82793 8.92% - 0s
0 0 -342.82793 0 27 -314.74133 -342.82793 8.92% - 0s
0 0 -342.82793 0 23 -314.74133 -342.82793 8.92% - 1s
0 0 -342.82793 0 24 -314.74133 -342.82793 8.92% - 1s
0 0 -342.82793 0 22 -314.74133 -342.82793 8.92% - 1s
0 0 -342.82793 0 21 -314.74133 -342.82793 8.92% - 1s
0 0 -342.82793 0 22 -314.74133 -342.82793 8.92% - 1s
0 0 -342.82793 0 21 -314.74133 -342.82793 8.92% - 1s
0 0 -342.82793 0 21 -314.74133 -342.82793 8.92% - 1s
0 0 -342.82793 0 20 -314.74133 -342.82793 8.92% - 2s
0 0 -342.82793 0 20 -314.74133 -342.82793 8.92% - 2s
0 0 -342.82793 0 20 -314.74133 -342.82793 8.92% - 2s
0 0 -342.82793 0 20 -314.74133 -342.82793 8.92% - 2s
0 2 -341.60586 0 20 -314.74133 -341.60586 8.54% - 2s
197 93 cutoff 12 -314.74133 -339.07047 7.73% 32.4 5s
H 331 117 -316.87406 -338.67591 6.88% 30.6 6s
* 331 117 13 -316.87406 -338.67591 6.88% 31.5 6s
H 682 160 -317.71236 -327.96254 3.23% 35.1 9s
* 682 160 21 -317.71236 -327.96254 3.23% 35.5 9s
740 176 -321.33161 18 11 -317.71237 -327.96254 3.23% 36.7 10s
H 1098 182 -317.71242 -326.36711 2.72% 40.8 14s
1220 191 -325.47241 11 18 -317.71243 -325.48670 2.45% 41.3 15s
H 1396 180 -317.71243 -324.06093 2.00% 42.6 16s
1690 122 cutoff 16 -317.71243 -322.94542 1.65% 43.6 20s
H 1706 122 -317.71243 -322.73823 1.58% 43.5 20s
H 1723 122 -317.71243 -322.60882 1.54% 43.5 20s
H 1944 93 -317.71243 -322.17601 1.40% 43.3 22s
H 2000 93 -317.71243 -321.64425 1.24% 43.4 22s
2205 28 cutoff 14 -317.71244 -319.99175 0.72% 43.2 25s
Cutting planes:
Implied bound: 50
Explored 2359 nodes (104167 simplex iterations) in 25.81 seconds (7.24 work units)
Solution count 3: -317.712-316.874-314.741
Optimal solution found (tolerance 1.00e-04)
Best objective -3.177124369613e+02, best bound -3.177127128559e+02, gap 0.0001%
-
-
Gurobi Staff
Hi Manuel,
It may happen for particular models that the performance gets worse when upgrading to a new version.
In your case however, it looks like the performance difference is connected to the large coefficient ranges.
The range of the coefficients in your quadratic constraints is
QObjective range [8e-06, 9e+10]
These are 16 order of magnitude of difference and is terrible from a numerical point of view. Such big coefficient differences may lead to any spurious behavior. For example, a factorization may be good or bad depending on the 16th overall digit. Given normal double machine precision of 16 digits, this means that the quality of the optimization process may drastically depend on the underlying elementary numerical operations.
In your particular case, it looks like v9.5.2 got a bit more lucky with numerics and can converge faster. This makes sense as we tried to make the numerical behavior of v10 more robust.
I would strongly recommend to try to re-scale the quadratic part of your model. You can find more details in our Guidelines for Numerical Issues.
Best regards,
Jaromił0 -
Please sign in to leave a comment.
Comments
1 comment