Originally posted by: Michael_D
Pardon me for jumping in, but this thread is really disconcerting.
Does this mean that in cplex 12.3, instead of the former cut callback, there are three callbacks to be implemented: lazy constraint callback, cut callback (as you write earlier, it is also sensible to check the lazy constraints during the cut loop), and incumbent callback (to handle case (b))?
Why shouldn't the lazy constraint callback be called under all circumstances before a potential solution is declared an 'incumbent'? If the lazy constraint callback is not called, it is impossible to say whether a potential incumbent is feasible, that is, fulfils all constraints, including the lazy ones.
What do you mean by 'heuristics that look close to the LP optimum and for which adding lazy constraints tightens the formulation at the area of interest'? How can cplex know whether or not 'adding lazy constraints tightens the formulation at the area of interest' when the lazy constraints are not separated?
Could it be that also in version 12.2, the cut callback may or may not be called when a potential incumbent is found by a heuristic, although the documentation (version 12.2) says: 'An instance of the class IloCplex::CutCallbackI represents a user-written callback in an application that uses an instance of IloCplex to solve a mixed integer programming problem (a MIP). This class offers a method to add a local or global cut to the current node LP subproblem from a user-written callback. CPLEX also calls the callback when comparing an integer feasible solution, including one provided by a MIP start before any nodes exist, against lazy constraints.' (IDE and OPL > OPL Interfaces > C++ interface reference manual > optim.cplex.cpp.advanced > Classes > Class IloCplex::CutCallbackI)?
Thanks in advance for shedding some light on this issue.
Michael
#CPLEXOptimizers#DecisionOptimization