• Gurobi Staff

This rare case may happen if a heuristics gets "stuck" in some improvement loop and takes an unusually high amount of time. Could you please share the model such that we can have a closer look?

May I know if I should reformulate my model to solve this problem, or I should change some parameters?

It seems hard to find a first feasible point for your model. You could try providing a MIP Start, see How do I use MIP start? You could also try experimenting with the NoRelHeurTime parameter to try to find a feasible point early. A value of 600 should be a good start. You could also experiment with the parameters MIPFocus=1 and increase the value of the Heuristics parameter.

Additionally, you might want to have a look at our Tech-Talk about weak and strong MIP formulations, see also General modeling tips to improve a formulation.

Best regards,
Jaromił

Jaromil,

Thank you for your suggestions. I am not able to share the model in here, but I am sure the talk would be helpful. I will look at the talk. Thank you!

Jaromil,

I watched the tech talk and reformulated my model. It helped a lot. Now it is able to find the first feasible point in about 700 seconds. However, it still stuck at some iteration for a long time.

Since you said it may be some heuristics got stuck, I tried to set the Heuristics parameter to 0. It is strange to me that even without heuristics, the model still got stuck at one of the iterations. Do you think the "stuck" was caused by something else?

I have a some complex conditional constraints in my model. I wonder if those would caused those problems.

For example, a <= b + (3 - c - d- e) and a >= b + (3 - c - d- e), where all the variables are binary. I meant to make a equals b, when c, d, and e all equal to 1.

• Gurobi Staff

Hi Mingze,

I'll jump in as I know Jaromił is away on leave for a while.

I don't think your conditional constraints are causing an issue here.  There are other reasons which can cause the behavior you see, which include restarts (kind of like a recalibration and recalculation of certain things) or a node with numerical issues.  I don't see signs of numerical issues in your log, my guess is that it is a restart.

Note that prior to the gap in the log you do not find any solutions, yet relatively soon afterwards you find many.  Whatever Gurobi is doing during this gap in the log looks to be a good thing - I would not assume it is something to be avoided (and I don't think you can avoid it).

- Riley

I see. Thank you, Riley.