Impact of Parameter SolutionLimit
Answered
I am using gurobi via the C++ Interface on a regular MIP model. I didn't disable presolve, I set the MIPFocus to 0 for finding feasible solutions fast and I set a TimeLimit of 30 sec.
With this setup the solver can not find a solution and terminates with a TimeLimt after 30 sec. This is the log file:
Gurobi 9.5.1 (mac64[rosetta2]) logging started Wed May 10 20:23:21 2023
Set parameter LogFile to value "../out/tmp/test_no_sol_lim.log"
Set parameter LogToConsole to value 0
Set parameter TimeLimit to value 30
Gurobi Optimizer version 9.5.1 build v9.5.1rc2 (mac64[rosetta2])
Thread count: 8 physical cores, 8 logical processors, using up to 8 threads
Optimize a model with 19425 rows, 34440 columns and 2833412 nonzeros
Model fingerprint: 0x9a348abb
Variable types: 0 continuous, 34440 integer (34440 binary)
Coefficient statistics:
Matrix range [1e+00, 2e+04]
Objective range [6e+00, 4e+01]
Bounds range [1e+00, 1e+00]
RHS range [1e+00, 3e+04]
Presolve removed 6898 rows and 18586 columns
Presolve time: 4.51s
Presolved: 12527 rows, 15854 columns, 1904270 nonzeros
Variable types: 0 continuous, 15854 integer (15798 binary)
Deterministic concurrent LP optimizer: primal and dual simplex
Showing first log only...
Root simplex log...
Iteration Objective Primal Inf. Dual Inf. Time
0 8.8450000e+02 6.400000e+03 3.650002e+08 5s
Concurrent spin time: 0.00s
Solved with dual simplex
Root relaxation: objective 1.537126e+04, 9506 iterations, 5.10 seconds (11.05 work units)
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 15371.2572 0 676 - 15371.2572 - - 10s
0 0 15433.1379 0 822 - 15433.1379 - - 13s
0 0 15472.7621 0 1035 - 15472.7621 - - 15s
0 0 15488.2854 0 1096 - 15488.2854 - - 16s
0 0 15492.2092 0 1130 - 15492.2092 - - 17s
0 0 15492.8961 0 1144 - 15492.8961 - - 18s
0 0 15493.0053 0 1179 - 15493.0053 - - 18s
0 0 15493.0405 0 1177 - 15493.0405 - - 18s
0 0 15493.0544 0 1183 - 15493.0544 - - 18s
0 0 15493.0574 0 1183 - 15493.0574 - - 18s
0 0 15496.8678 0 1313 - 15496.8678 - - 23s
0 0 15506.4745 0 1396 - 15506.4745 - - 26s
0 0 15509.4313 0 1489 - 15509.4313 - - 27s
0 0 15510.3575 0 1530 - 15510.3575 - - 28s
0 0 15510.6248 0 1589 - 15510.6248 - - 29s
0 0 15510.7166 0 1616 - 15510.7166 - - 29s
0 0 15510.7557 0 1634 - 15510.7557 - - 29s
Cutting planes:
Cover: 49
MIR: 185
StrongCG: 2
GUB cover: 585
RLT: 106
Explored 1 nodes (26961 simplex iterations) in 30.01 seconds (61.66 work units)
Thread count was 8 (of 8 available processors)
Solution count 0
Time limit reached
Best objective -, best bound 1.551075570238e+04, gap -
User-callback calls 6010, time in user-callback 0.00 sec
When I run the same model and just add a SolutionLimit of 1, I obviously get the same model (and I compared the model files - they are exactly the same), the solver finds a feasible solution after 17 sec. This is the log file:
Gurobi 9.5.1 (mac64[rosetta2]) logging started Wed May 10 20:24:24 2023
Set parameter LogFile to value "../out/tmp/test_sol_lim.log"
Set parameter LogToConsole to value 0
Set parameter TimeLimit to value 30
Set parameter SolutionLimit to value 1
Gurobi Optimizer version 9.5.1 build v9.5.1rc2 (mac64[rosetta2])
Thread count: 8 physical cores, 8 logical processors, using up to 8 threads
Optimize a model with 19425 rows, 34440 columns and 2833412 nonzeros
Model fingerprint: 0x9a348abb
Variable types: 0 continuous, 34440 integer (34440 binary)
Coefficient statistics:
Matrix range [1e+00, 2e+04]
Objective range [6e+00, 4e+01]
Bounds range [1e+00, 1e+00]
RHS range [1e+00, 3e+04]
Presolve removed 6898 rows and 18586 columns
Presolve time: 4.61s
Presolved: 12527 rows, 15854 columns, 1904270 nonzeros
Variable types: 0 continuous, 15854 integer (15798 binary)
Deterministic concurrent LP optimizer: primal and dual simplex
Showing first log only...
Root simplex log...
Iteration Objective Primal Inf. Dual Inf. Time
0 8.8450000e+02 6.400000e+03 3.650002e+08 5s
Concurrent spin time: 0.00s
Solved with dual simplex
Root relaxation: objective 1.537126e+04, 9506 iterations, 5.08 seconds (11.05 work units)
Total elapsed time = 10.03s
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 15371.2572 0 676 - 15371.2572 - - 10s
0 0 15433.1379 0 822 - 15433.1379 - - 13s
0 0 15472.7621 0 1035 - 15472.7621 - - 15s
0 0 15488.2854 0 1096 - 15488.2854 - - 17s
H 0 0 47594.610000 15488.2854 67.5% - 17s
Cutting planes:
Cover: 26
MIR: 109
GUB cover: 393
RLT: 50
Explored 1 nodes (5455 simplex iterations) in 17.25 seconds (33.78 work units)
Thread count was 8 (of 8 available processors)
Solution count 1: 47594.6
Solution limit reached
Best objective 4.759461000000e+04, best bound 1.548828543420e+04, gap 67.4579%
User-callback calls 4541, time in user-callback 0.00 sec
This behaviour confuses me, as for know I always thought, that setting a Limit (of any type) just adds a termination criterion to the solver and that doesn't impact the results of an optimisation run.
So my question is, if this behaviour is normal, or shouldn't the SolutionLimit impact the optimisation run (apart from terminating it when a solution was found) and it's likely that the are some deeper issues with my model?
-
Setting the SolutionLimit parameter to 1 affects Gurobi's algorithmic behavior. From the current SolutionLimit documentation:
To find a feasible solution quickly, Gurobi executes additional feasible point heuristics when the solution limit is set to exactly 1.
1 -
Perfect, thanks - I should have read the documentation more carefully.
0
Please sign in to leave a comment.
Comments
2 comments