Gurobi stucks even after the time limit
Answered
Hi, i solved a MIP model within a 5% relative tolerance. I wanted more accurate results, then i reduced the tolerance to 3% and set a time limit of 30 hours. As you can see on the log , it stucks at 10704 and seems to do nothing anymore. Moreover after the time limit, the optimization don't stop. Its just stucked.
-
From your log I see that you provided a TimeLimit value of 108000 instead of 10800. Thus, I cannot see anything wrong with the Gurobi log output.
You might want to experiment with the NoRelHeurTime parameter, which executes a special so-called "no relaxation" heuristic, which tries to find good feasible solutions even before the B&B algorithm starts. Setting this value to something like 1200 or 1800 should be reasonable for initial testing.
Best regards,
Jaromił0 -
Thank you for your quick answer, but there is no error about the time limit. 30 hours= 108000 seconds. and even after the 30 h it doesn't stop. I will try NoRelHeurTime parameter. I hope it could solve the problem.
0 -
Thank you for your quick answer, but there is no error about the time limit. 30 hours= 108000 seconds.
Ok, then I am confused by your statement.
As you can see on the log , it stucks at 10704 and seems to do nothing anymore. Moreover after the time limit, the optimization don't stop. Its just stucked.
From the above screenshot, I do not see the optimization getting stuck at 10704 seconds nor running into the timelimit of 108000 seconds. Is there a part of the screenshot missing?
0 -
The screenshot shows you the end of the log file. There is no missing part. The optimization is not terminated at this point , but nothing happens after the last line (27679 s). The log file is not updated anymore, and even after reaching the time limit (108000) it is still pending. I have to interrupt it (several hours after the time limit) , by restarting the kernel (I'm working on jupyterlab). There is no error code and then the log file you see, is the logfile i got after interrupting the optimization by myself.
I don't know if this information is useful, but the size of the log file is always 64ko when it starts "pending". I tried 2 times with a slightly different model. However, even when i chose to not generate the logfile the same problem occurs. The optimization go beyond the time limit and don't stop until i interrupt it.
Note that after it stucks, i can see on the performance screen of my task manager that my processors are not working on it anymore.
0 -
Thank you for the explanation. Now the output makes sense.
Could you please try updating to version 11.0.3?
Could you please share your model such that we can have a close look? Note that uploading files in the Community Forum is not possible but we discuss an alternative in Posting to the Community Forum.
Best regards,
Jaromił0 -
Sure, Here is the link to download the mps file : https://filesender.renater.fr/?s=download&token=c18a33b8-2fbf-45a5-9198-dbbad3f19d32 .
Kind regards,
jean
0 -
Thank you for the model, Jean. I will try to reproduce the behavior on our side.
0 -
Hi Jean,
I tried to reproduce the behavior you described with the upcoming version 12, which will be released very soon (in the upcoming weeks). It would be great if you could upgrade to v12 once it is out and try it out yourself. Please let us know if the issue still occurs on your side even with v12.
In the meantime, you could try experimenting with the NoRelHeurTime parameter. Since your timelimit for 3% MIPGap is 30h, you might want to set NoRelHeurTime=5*3600 or 10*3600, so to 5 or 10 hours.
Best regards,
Jaromił0 -
Hi Jaromil ,
I finally tried to solve my model directly from the Gurobi command line with the .mps file and it's worked. Then, the problem doesn't come from Gurobi but should be on another level. In fact I use Gurobi through JuMP , on Jupyter Lab. I will try to figure out where the problem occurs, and maybe raise a point on the Julia forum.
Thank you for your assistance,
Jean
0
Please sign in to leave a comment.
Comments
9 comments