MIP start takes very long to process
AnsweredDear community,
I have a large MIP (solve with a BendersDecomp / callbacks) for which I know several feasible solutions, the best of which I provide to the model as a MIP start. the MIP start includes all binaries of the model.
Still, the solver takes a long time to process the MIP start (see log below). Thus this mean that it simply takes that long to evaluate the MIP start, i.e. to check if for feasibility? Is there a way to speed it up, given that I know the solution to be feasible?
Thank you!
Set parameter CSQueueTimeout to value 120
Set parameter ServerTimeout to value 10
Set parameter TokenServer to value 10.152.187.2
Set parameter CSIdleTimeout to value 60
Changed value of parameter LazyConstraints to 1
Prev: 0 Min: 0 Max: 1 Default: 0
Parameter OutputFlag unchanged
Value: 1 Min: 0 Max: 1 Default: 1
Changed value of parameter Threads to 12
Prev: 0 Min: 0 Max: 1024 Default: 0
Changed value of parameter Presolve to 2
Prev: 1 Min: 1 Max: 2 Default: 1
Changed value of parameter TimeLimit to 259200.0
Prev: inf Min: 0.0 Max: inf Default: inf
Gurobi Optimizer version 9.1.0 build v9.1.0rc0 (linux64)
Thread count: 32 physical cores, 64 logical processors, using up to 12 threads
Optimize a model with 7885 rows, 14639 columns and 77998 nonzeros
Model fingerprint: 0x86c37d94
Variable types: 1 continuous, 14638 integer (14638 binary)
Coefficient statistics:
Matrix range [1e+00, 6e+05]
Objective range [1e+00, 1e+00]
Bounds range [1e+00, 1e+00]
RHS range [1e+00, 5e+00]
Loaded user MIP start with objective 1.34744e+06
Processed MIP start in 1971.01 seconds
Presolve removed 7801 rows and 7801 columns
Presolve time: 1.54s
Presolved: 84 rows, 6838 columns, 41019 nonzeros
Variable types: 1 continuous, 6837 integer (6813 binary)
Presolved: 84 rows, 6838 columns, 41019 nonzeros
Root simplex log...
Iteration Objective Primal Inf. Dual Inf. Time
0 0.0000000e+00 6.258823e+02 0.000000e+00 1973s
202 1.0925736e+06 0.000000e+00 0.000000e+00 1973s
202 1.0925736e+06 0.000000e+00 0.000000e+00 1973s
Root relaxation: objective 1.092574e+06, 202 iterations, 0.02 seconds
Nodes  Current Node  Objective Bounds  Work
Expl Unexpl  Obj Depth IntInf  Incumbent BestBd Gap  It/Node Time
0 0 1092573.62 0 43 1347444.14 1092573.62 18.9%  1972s
H 0 0 1299911.7295 1092573.62 16.0%  1972s
H 0 0 1193626.9567 1092573.62 8.47%  1972s
0 0 1094706.85 0 62 1193626.96 1094706.85 8.29%  1972s
H 0 0 1117601.3633 1094706.85 2.05%  1972s
0 0 1094991.47 0 64 1117601.36 1094991.47 2.02%  1972s
0 0 1095175.45 0 60 1117601.36 1095175.45 2.01%  1972s
0 0 1095201.47 0 66 1117601.36 1095201.47 2.00%  1972s
0 0 1096008.36 0 55 1117601.36 1096008.36 1.93%  1972s
0 0 1096008.36 0 45 1117601.36 1096008.36 1.93%  1973s
H 0 0 1099188.6805 1096008.36 0.29%  1973s
0 0 1096008.36 0 58 1099188.68 1096008.36 0.29%  1973s
0 0 1096008.36 0 41 1099188.68 1096008.36 0.29%  1974s
0 0 1097889.47 0 58 1099188.68 1097889.47 0.12%  1974s
0 0 1098870.69 0 8 1099188.68 1098870.69 0.03%  1974s
0 0 cutoff 0 1099188.68 1099188.68 0.00%  1974s
Cutting planes:
Gomory: 3
Clique: 4
GUB cover: 3
RLT: 1
Explored 1 nodes (864 simplex iterations) in 1974.30 seconds
Thread count was 12 (of 64 available processors)
Solution count 5: 1.09919e+06 1.1176e+06 1.19363e+06 ... 1.34744e+06
Optimal solution found (tolerance 1.00e04)
Best objective 1.099188680506e+06, best bound 1.099188680506e+06, gap 0.0000%
Usercallback calls 506, time in usercallback 1971.02 sec

Hi Mike,
Could you try setting the parameter StartNodeLimit to 2? Does this resolve the issue?
Best regards,
Jaromił1 
Hi Jaromil,
thanks a lot for the answer! It did improve the performance. However, I opted now to simply retreive solution from .sol files that I generate with an easy to solve version of the model.
Related to .sol files, is there a way to query .sol files and select the one as a MIP start that has the best objective value, i.e. the best starting solution?
Thank you and best regards,
Mike
0 
As a followup question: When I start from a .sol file I still get the message that the MIP start did not produce a new incumbent solution.
This also happens if I generate the .sol file from the same identical model where I want to use the MIP start. Just for checking the process this should work. However, even though simply generate files with
model.setParam('SolFiles', myPath)
and read with
model.read(myPath)
I still get
User MIP start did not produce a new incumbent solution
is there a reasonable explanation, something that I might be missing?
Thank you very much!
0 
Hi Mike,
You can provide multiple SOL files via the InputFile parameter if you are running from command line, e.g.,
>gurobi_cl InputFile=sol1.sol InputFile=sol2.sol myModel.lp
Setting multiple initial points is explained in the documentation of the Start parameter.
Best regards,
Jaromił0 
I don't see a proper explanation for the behavior you describe. Could you provide a minimal working example?
0 
Hi Jaromil,
In the meantime I fixed the issue, I believe it was somehow related to my callback procedure.
Thank you for your assistance!
0
Please sign in to leave a comment.
Comments
6 comments