Callback is not being called in optimal solution

[esmaeel moradi]

Hi,

I am using callback and I encountered a problem. 
My code calls callback whenever it finds a new incumbent (where = GRB_CB_MIPSOL) but in the optimal solution, the code does not go through callback and reports the optimal solution. Therefore, sometimes the reported optimal solution is not the real optimal solution that I want. 

I tried to change the Heuristic parameter to zero, but it does not work. Could anybody please help me to solve this problem. Appreciate your time and consideration.

Bests,

Esmaeel

[Sonja Mars]

Hi Esmaeel,

Do you have a small example lp or mps file for which you can see this behavior? If so, please post it here. I was not able to reproduce it with a bunch of different models I tried.

Thanks,
Sonja

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "Gurobi Optimization" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gurobi+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[esmaeel moradi]

Sonja,

Thank you for your reply. I have attached the shortest example that I could make. 

I am adding lazy constraints whenever it finds new incumbent. Very before when the code wants to stop, it calls Callback, add some lazy cuts, but then never comes back to Callback and reports the optimal solution. I know that When it adds new cuts at the very last Callback call, it should find new incumbent and check the Callback to see it needs new cuts or not (which actually it needs). Hope I could give you some view of my code. I really appreciate any kind of help. Please let me know if you have any other questions regarding my problem.

Again thank you for your time and consideration.

Esmaeel

[Sonja Mars]

Hi Esmaeel,

I am sorry, but I cannot debug your code. From your first email it looked like you are just using the where=GRB_CS_MIPSOL callback for reporting things. In this case you could send a lp or mps file and I could try to reproduce it, but your setting is much more complicated.

Nevertheless, I will try to raise some questions and make some suggestions. Maybe someone else from the community has some other helpful ideas.

Just to make sure I understand everything correctly: Your code using lazy constraints and Gurobi does not produce a feasible solution, because the callback isn’t called sufficiently often?

> I know that When it adds new cuts at the very last Callback call, it should find new incumbent

What do you mean by "should find”? Did it found a new incumbent or not? If no new incumbent is found, your callback will not be called.

Are you sure the lazy constraints added in the end, definitely cut off the last incumbent found? You should double check that.

-- Sonja

[esmaeel moradi]

Hi Sonja,

Yes I know it is a little bit complicated. But I could find the problem in this version of my code, sorry.

My code calls callback and adds lazy constraints. In the callback class, it checks one condition to see if it needs lazy constraints or not. My problem is, at the last time that it calls the callback, it ADDS lazy constraints (therefore it should get new incumbent and come back to callback again) but after that, the code reports the optimal solution. Actually, the optimal solution is feasible for the problem till now but not optimal for me, since if it calls callback again and checks the condition, the code would add new lazy constraints! Hope it helps

Appreciate your time

Esmaeel 

[Andrew Orso]

I am having a similar issue, seems like things are running fine and it generates a new lazy constraint that should prompt a new callback but it never does and terminates way earlier than it should. Was there a resolution to this?

[Greg Glockner]

You should double-check your code for the following:

1. That you are setting the LazyConstraints parameter
2. That you are adding lazy constraints *whenever* they are violated -- regardless of whether you have added them before. (Remember, Gurobi Optimizer is a multi-threaded code so one computing node may not currently have the cut status of other nodes).

In other words, add a lazy constraint whenever you see it violated. Don't try to "outsmart" the solver by keeping a list and only adding constraints that aren't on your list.

[Ed Rothberg]

What version are you using?  There was a bug that could produce this symptom that I believe was fixed in version 5.6.1 (current version is 5.6.3).

Ed

[Fabien Tricoire]

Has there been a fix for that issue? We are experiencing exactly the same problem, using Gurobi version 6.0.0.

We add a lazy constraint that is violated by the current solution, with where = MIPSOL. Then the next thing that happens is that the model is optimal, without ever triggering the callback with where=MIPSOL, thus leaving us no chance to add new cuts that would nonetheless be necessary.

Thanks in advance for your help.