Impact of Parameter SolutionLimit
AnsweredI 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 
Usercallback calls 6010, time in usercallback 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%
Usercallback calls 4541, time in usercallback 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