Originally posted by: mrmag

Thank you in advance!

The normal behavior of CPLEX when a cut callback adds a cut is to update the LP solution and, if the node is not pruned, call the cut callback again, repeating until the cut callback fails to add a cut. So, things to check:

1. Print your cut before adding it and verify that it is correct and actually alters the LP solution. (I'm not sure whether CPLEX will call the callback again if the node LP solution is not altered by the most recent cut.)
2. Verify that the node LP is still feasible and has objective value better than the incumbent solution after adding the cut (otherwise, CPLEX may prune the node and switch to another node).
3. Try changing add(cut).end() to just add(cut). It's been a while since I used the C++ API (the Java API is a bit different), but I believe that if you add a constraint to a model and end it immediately, the constraint is removed from the model. Whether that is also true for cuts (which are added to an IloCplex object rather than an IloModel object) I can't recall. (This is easiest to test, so perhaps I should have listed it first.)

Paul

Originally posted by: EdKlotz

As Paul said, CPLEX normally will reoptimize the node LP at which cuts were applied (either by CPLEX or the user), then call the cut callback function again.   Reasons CPLEX would stop repeatedly calling the cut loop include

• The node LP is infeasible after the cuts are added.   Make sure your cuts aren't tighter than intended.  Print the cut, as Paul recommended.   You could also create a solve callback function to get a clearer picture of how the node LP solves.
• Your cut callback tells CPLEX to stop.   I doubt this is the problem in your case, as this would only happen if your callback had an abort() call present, or did some unusual exception handling.   But, please double check this just in case.
• Some CPLEX function in CPLEX's internal cut loop that calls your cut callback returns a nonzero status.   As long as your code uses try/catch blocks and catches IloExceptions, I doubt this is the case, as it would have appeared as an exception.
• The node LP solve after adding cuts (including user supplied lazy constraints) is no longer integer infeasible.   Could this explain the behavior you see?   If you added a lazy constraint, and the resulting node LP solve was integer feasible, CPLEX would exit the cut loop.   However, in that case, if you wanted to reject that integer feasible solution and apply more of your cuts, I think you could accomplish that with a combination of incumbent callback function and branch callback function.   You could use the incumbent callback function to decide if you want to reject the integer feasible solution or keep it.   If you reject it, the node remains active.   Since CPLEX itself doesn't have any branching logic for integer feasible node relaxations, you would then need to supply a branching rule for this node with your branch callback function.   You would probably want this to execute only when the node relaxation solution had zero integer infeasibilities; otherwise just let CPLEX branch.   Presumably you would use one of your cuts in the branching rule.   This would then create child nodes.   While CPLEX may not select those nodes immediately, eventually it will process them, at which point your cut callback will have the opportunity to add more lazy constraints.

I hope this helps.   If not, please include some output of the CPLEX node log that illustrates the cases where CPLEX appears to stop reiterating through the same node relaxation.

Also, in case it helps, I have attached an example C++ program that solves a travelling salesman problem using subtour elimination constraints.    That seems like a similar application to yours, so perhaps running that application will help you determine the unexpected behavior in yours.

Ed

Originally posted by: mrmag

Dear Ed and Paul, I recoded every according to the example and everything works now. Thank you!