Originally posted by: regisgomes

I'm using lazy constraint callback to test the viability of incumbent solutions, if not, I insert cuts.

But it seems that this callback does not evaluate the last incumbent solution. Therefore, a infeasible final solution is accepted, since it appears that the callback does not evaluate the latter solution.

The following image provides some information. The callback is invoked twice with the infeasible solution 436, and only inserts two cuts. For my analysis should have been invoked only once for the infeasible solution 436. The problem is that it is incumbent found an infeasible solution with value 423 that has not been evaluated and is therefore accepted and finishing the run with an infeasible solution.

Am I doing something wrong or there is some bug do not know?

I am using version 12.5.

Thank you very much in advance.

Is it an option to upgrade to a more recent version of CPLEX?

In the past we have a fixed a number of bugs with lazy constraint callbacks (including cases in which CPLEX failed to invoke the callback on certain solutions). So it may well be that you bumped into something that has been fixed by now.

If upgrading CPLEX is not an option: what happens if you additionally install an incumbent callback? Is that callback invoked for solution 423? If so then you could reject the solution from there.

Originally posted by: regisgomes

Daniel, thanks for the reply.

I installed the 12.6.2 version and the fault persists.

I send attached an image that exemplifies the failure.

Note that the lazycallback is called after finding the solution 274 (second incumbent solution) and then evaluates the first incumbent solution founded which is 276. It seems that there is a delay. Is there any parameter of the callback that can doing this?

Thank you in advance.

Do I understand correctly from your log that the callback _is_ invoked at the right time (right before the solution 274 is processed) but apparently it is invoked with the wrong solution?

How do you get the objective value 276 that you print in the callback? Do you calculate this yourself or do you get this from some CPLEX function?

Also, how are you separating lazy constraints? Do you separate them from a table or do you have a dynamic separation algorithm? Note that in certain cases it may happen that you have to separate a constraint more than once! In other words, if you separate constraint C in a callback then you can not assume that at the next invocation of the callback constraint C is in the model. You have to check _again_ whether it is violated.

Originally posted by: regisgomes

Do I understand correctly from your log that the callback _is_ invoked at the right time (right before the solution 274 is processed) but apparently it is invoked with the wrong solution?

That's it.

How do you get the objective value 276 that you print in the callback? Do you calculate this yourself or do you get this from some CPLEX function?

I use getIncumbentObjValue() command.

Also, how are you separating lazy constraints? Do you separate them from a table or do you have a dynamic separation algorithm? Note that in certain cases it may happen that you have to separate a constraint more than once! In other words, if you separate constraint C in a callback then you can not assume that at the next invocation of the callback constraint C is in the model. You have to check _again_ whether it is violated.

I use a dynamic separation algorithm. The cut is added without problem. But that I stopped caring. Because I use getIncumbentValue() command to get the variables values of  incumbent solution, but how these values are of previous solution, the cut produced only applies to previous solution and not to current solution, ie generates a cut to 276 solution, but the solution that is active is 274 (which is not feasible).

Continue to wait any help.

In the lazy constraint callback, don't use any method that has 'incumbent' in its name. The callback is invoked with a candidate incumbent that may still be rejected. So the current solution is not yet the incumbent. The incumbent is the last solution that was not rejected by the callback. I guess this is why it looks to you as if the callback was invoked for the previous solution.

Use getObjValue() and getValue()/getValues() (see the reference documentation) in the callback to assess the candidate incumbent.

I wonder what happens if your callback is invoked for the very first time. At that point there is no incumbent and functions like getIncumbentValue() should throw an exception while getIncumbentObjValue() should return a very large value. Didn't you see any of this happening?

Originally posted by: regisgomes

Dear Daniel,

Now it is working as I want.

Thank you very much.