• Gurobi Staff

No, the CutPasses parameter should do the trick. Could it be that you encountered an integer solution on the way (I mean that the LP solution was integral)? When lazy constraints are involved, things get more complicated (and I would need to look more carefully at our source code).

If lazy constraints are not involved and the CutPasses parameter is set to a large value, then I am pretty sure that the cut loop will only be aborted if no cuts have been found.

Maybe, you are adding a cutting plane that is violated only a little bit and Gurobi (after scaling the cut) dismisses the cut as being not violated enough. In this case, if this was the only cut that was added, it will then think that no cuts have been found and abort the loop.

Thank you for the reply. I do encounter integer solutions on the way, but after some more debugging I find that the cut loop is aborted after adding a lazy constraint in MIPNODE. What I referred to as cuts of type 1 should probably be explained a bit more precise. They are actually subtour elimination constraints consisting of two subgroups, namely capacitated subtour eliminations and standard subtour eliminations. I referred to them as cuts of type 1 as they are both found using the same separation algorithm. However, the capacitated subtour eliminations are actually not cutting planes, they are added as lazy constraints, because they define the original model. The standard subtour eliminations are then used as tightening cutting planes, added as lazy constraints in MIPSOL and as cutting planes in MIPNODE. The loop does not abort the first time a lazy constraint is added, but after several iterations, probably when the improvement of the dual bound is too small. Could that be the problem, that Gurobi doesn't find any cut to be violated enough and only being left with the lazy constraints the algorithm decides to start branching?

An alternative approach would be to solve the root node as an LP and add the cuts and the lazy constraints in my own loop resolving the LP until no more cuts or lazy constraints can be found. Then after this, change the definition back to an integer program and start branching. However, I was hoping to do this setting a parameter, because then I could get the same behavior throughout the branch-and-bound tree. Do you think this is still possible when including lazy constraints?

• Daniel Espinoza

Hi Jorgen,

It could be that the solver decides to stop cutting due to small dual bound movement... if you think about it, it is always possible to find a violated cut (e.g. a Gomory cut), and so the solver has to decide when is time to branch. Maybe a log could shed some light into the behavior you are seeing