I have a mixed integer optimization to be solved with Gurobi in JuMP. I am trying to give a warm start to Gurobi, but it gives me the following message
User MIP start did not produce a new incumbent solution
Processed MIP start in 1.13 seconds
My first question is, does this mean my solution is not accepted? And what would be the possible reasons in general?
It does not say any of my constraints are violated. Actually, I use JuMP with
LazyConstraintCallback, but I believe my warm start is feasible, and its objective value is better than the feasible solutions found by Gurobi within a certain time limit.
Then my second question is, what could be the reason that the warm start is not used by Gurobi in this case?
Thanks for the help.
It means your solution is not better than the incumbent found by Gurobi. There can be multiple reasons for this. It’s hard to say more without a reproducible example.
Thanks! I will see if I could find out the reason.
Try to find out if your point is feasible or not. If it’s infeasible, Gurobi is going to throw it away.
I am currently experiencing the same problem and for me the problem is that only the discrete values are given as a starting point - Gurobi then finds the continuous values itself and afterwards checks with the lazy-constraint callback. As the callback returns a cut (due to the continuous variables) the intitial solution is found to be infeasible and is discarded.
The problem is also discussed here:
A possible work around is to set the specific violated cut as a regular constraint (if it is possible to specify this beforehand) - this works in my case.
Thank you so much! I will look into it and see if it works for me!