I'm developing a Branch-and-cut algorithm, where I add user specific cuts and lazy constraints through a callback. I have encountered the problem that the cut generation in the root node seems to abort prematurely. I've been reading the responses in the following thread: https://groups.google.com/forum/#!topic/gurobi/_JUHVqdNy7s suggesting to set the CutPasses parameter sufficiently high in order to override the default heuristic abort criterion in Gurobi. However, setting this to it's maximum level I still encounter the same problem.
Currently I have three types of cuts, where the first type is fast to separate and the two last ones are slow to separate. Therefore, I would like to run a sequential separation routine where I first check for type 1 cuts, if none are found check for type 2 cuts, if none are found check for type 3 cuts, if none are found start branching. Setting the CutPasses parameter to it's maximum level I would expect the algorithm to go through all checks before starting to branch, but instead it will sometimes start branching immediately after adding a cut of type 1 without even checking for the other cut types.
Therefore, it seems to me that the heuristic abort criterion in Gurobi is still active, namely that the cut generation will abort once the marginal improvement of the objective value of the LP-relaxation (or the dual bound of the MILP problem) is below a given limit when adding a cut. If I have understood this correctly, does that mean the CutPasses parameter only overrides the abort criterion for the Gurobi-internal cuts, and not for the user specific callback cuts? Thus starting to branch as soon as no more Gurobi-internal cuts are added to the model, or the marginal improvement from the user specific cuts are too small.
I'm grateful for any feedback or clarification regarding this matter.
Please sign in to leave a comment.