Why the gap is so big?
Answered
Hello, everyone
I donot know why the Root relaxation was so small and the gap was so huge?
This problem is about the model or parameters?
solver+ Solver chosen : GUROBI-GUROBI
+ Processing objective function
+ Processing constraints
+ Calling GUROBI
Academic license - for non-commercial use only
Optimize a model with 721 rows, 408 columns and 1319 nonzeros
Model has 72 quadratic objective terms
Variable types: 288 continuous, 120 integer (120 binary)
Coefficient statistics:
Matrix range [9e-01, 1e+05]
Objective range [1e-02, 2e+03]
QObjective range [5e+00, 5e+00]
Bounds range [1e+00, 1e+00]
RHS range [1e+00, 1e+05]
Found heuristic solution: objective 2021327.9730
Presolve removed 481 rows and 120 columns
Presolve time: 0.00s
Presolved: 240 rows, 288 columns, 648 nonzeros
Presolved model has 72 quadratic objective terms
Variable types: 216 continuous, 72 integer (72 binary)
Root relaxation: objective -4.337444e+03, 497 iterations, 0.00 seconds
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 -4337.4436 0 72 2021327.97 -4337.4436 100% - 0s
H 0 0 -121.0583032 -4337.4436 3483% - 0s
0 0 -2897.4436 0 55 -121.05830 -2897.4436 2293% - 0s
0 0 -2389.2579 0 41 -121.05830 -2389.2579 1874% - 0s
0 0 -2281.0413 0 39 -121.05830 -2281.0413 1784% - 0s
0 0 -2281.0413 0 39 -121.05830 -2281.0413 1784% - 0s
0 0 -2281.0413 0 54 -121.05830 -2281.0413 1784% - 0s
0 0 -2281.0413 0 39 -121.05830 -2281.0413 1784% - 0s
0 0 -2281.0413 0 39 -121.05830 -2281.0413 1784% - 0s
0 2 -2281.0413 0 39 -121.05830 -2281.0413 1784% - 0s
H 9 12 -121.0588366 -2161.0416 1685% 16.8 0s
H 741 664 -121.0607032 -2161.0413 1685% 8.6 0s
10816 5212 -841.03168 28 15 -121.06070 -1381.0411 1041% 9.2 5s
21183 10145 -361.02975 36 4 -121.06070 -1201.0377 892% 8.8 10s
34326 15938 -421.03320 36 5 -121.06070 -1081.0390 793% 8.5 15s
46616 21239 -361.04385 39 5 -121.06070 -961.04568 694% 8.4 20s
60305 27152 -961.03006 31 14 -121.06070 -961.03006 694% 8.2 25s
73996 32717 -601.04657 34 8 -121.06070 -841.04577 595% 8.1 30s
87569 37817 -241.03578 42 4 -121.06070 -841.03915 595% 8.0 35s
100806 42944 -241.03184 35 2 -121.06070 -841.03278 595% 7.9 40s
114353 48123 -181.03723 46 3 -121.06070 -781.04130 545% 7.9 45s
127972 53511 -181.02814 49 1 -121.06070 -781.03099 545% 7.8 50s
141594 56230 cutoff 29 -121.06070 -721.04557 496% 7.8 55s
155684 58771 -481.04352 39 7 -121.06070 -721.04190 496% 7.8 60s
166585 60960 -241.03943 42 4 -121.06070 -721.04035 496% 7.8 65s
178725 63708 -181.03528 45 2 -121.06070 -721.03880 496% 7.7 70s
190556 65882 -181.03575 42 2 -121.06070 -721.03723 496% 7.7 75s
202389 68118 -361.04153 33 7 -121.06070 -721.03590 496% 7.7 80s
215451 71078 -481.03568 31 7 -121.06070 -721.03461 496% 7.7 85s
228049 73915 -181.02950 45 2 -121.06070 -721.03283 496% 7.7 90s
241242 76260 -361.03287 40 7 -121.06070 -721.03148 496% 7.7 95s
255930 80347 -661.02913 40 9 -121.06070 -721.02909 496% 7.7 100s
270054 83110 -181.04723 44 6 -121.06070 -661.04943 446% 7.7 105s
283578 86681 -361.03945 38 7 -121.06070 -661.04369 446% 7.6 110s
297183 90266 -361.03788 37 4 -121.06070 -661.04048 446% 7.6 115s
310462 93720 -361.03735 39 5 -121.06070 -661.03810 446% 7.5 120s
322570 96870 -181.03615 44 3 -121.06070 -661.03601 446% 7.5 125s
329468 98709 -241.03179 33 2 -121.06070 -661.03483 446% 7.5 130s
337710 100889 -361.03206 37 7 -121.06070 -661.03343 446% 7.5 135s
345686 102961 -481.03057 37 7 -121.06070 -661.03158 446% 7.5 140s
354035 105066 -181.02722 37 1 -121.06070 -661.03007 446% 7.4 145s
363891 107406 -481.05317 35 8 -121.06070 -601.05343 396% 7.4 150s
375472 108843 -541.04885 38 12 -121.06070 -601.04856 396% 7.4 155s
388190 110098 cutoff 37 -121.06070 -601.04659 396% 7.4 160s
401160 111495 -301.04364 39 4 -121.06070 -601.04516 396% 7.5 165s
414110 113101 cutoff 36 -121.06070 -601.04414 396% 7.5 170s
426472 114421 cutoff 34 -121.06070 -601.04306 396% 7.5 175s
438077 115618 -241.04068 35 2 -121.06070 -601.04237 396% 7.5 180s
450726 116888 -361.04170 37 6 -121.06070 -601.04170 396% 7.5 185s
462068 117945 -181.04031 43 3 -121.06070 -601.04115 396% 7.5 190s
472150 119149 -181.03814 40 1 -121.06070 -601.04064 396% 7.5 195s
479456 120029 -241.04093 36 3 -121.06070 -601.04029 396% 7.5 200s
Interrupt request received
Cutting planes:
MIR: 36
Explored 484296 nodes (3648070 simplex iterations) in 201.92 seconds
Thread count was 4 (of 4 available processors)
Solution count 4: -121.061 -121.059 -121.058 2.02133e+06
Solve interrupted
Best objective -1.210607032413e+02, best bound -6.010400844269e+02, gap 396.4783%
-
Official comment
-
Gurobi Staff
This post is more than three years old. Some information may not be up to date. For current information, please check the Gurobi Documentation or Knowledge Base. If you need more help, please create a new post in the community forum. Or why not try our AI Gurobot?. -
-
-
The huge gap means that the objective of the root relaxation (i.e., the optimal fractional solution) is far away from the best integer solution that has been found so far.
In your log, I can see that Gurobi moves the bound quite a bit, from -4337.444e at the end of the root relaxation to -601.04029 when you interrupted the solve, while the incumbent solution is barely moving.
You could experiment with different values of the MIPFocus parameter or more aggressive cuts to make the bound move faster, but if you could improve the model by tightening the LP relaxation (i.e., change your constraints or add new ones so that the optimal solution of the root relaxation gets closer to the optimal integer solution), that would probably help a lot more.
0 -
Post is closed for comments.
Comments
2 comments