Originally posted by: JorisK

Dear,

I'm trying to solve a MIP model where some cuts are added through the Lazy Constraint callback (cplex 12.4, Java interface). When I run my implementation on some test instances, everything seems to work fine: the results are correct. However, when I first generate a solution using some heuristic, and feed this to the MIP model as a warm start (addMipStart() ), I get some awkward results: the lazy constraint callback is invoked with a fractional solution (the model only has boolean variables). Isn't it true that this callback is only invoked on integer solutions? Below is my implementation of the Lazy Constraint Callback:

private class LazyConstraintCallbackImpl extends IloCplex.LazyConstraintCallback {

 

    @Override

    protected void main() throws IloException {

//mipData.flowVars is an array of IloIntVar (boolVars)

double[] values=this.getValues(mipData.flowVars);

System.out.println("Values:\n"+Arrays.toString(values));

for(int i=0; i<values.length; i++)

values[i]=CplexUtil.doubleToRoundedDouble(values[i]);

 

List<IloConstraint> newCuts=subtourSeparator.getCuts(values);

for(IloConstraint cut: newCuts)

this.add(cut);

    }

}

The System.out in the above code prints:

Values: [0.0, 0.0, 0.5463610315186248, 0.0, 0.0, 0.0, 0.0, 0.0, 0.4536389684813752, 0.0, 0.0, 0.0, ........., 0.0, 0.0, 0.0, 0.0, 0.6804584527220632, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9072779369627508, 0.0, 0.09272206303724917, 0.0, 0.0]

These fractional values are certainly no rounding errors. My application terminates (crashes) as it expected that the lazy constraint callback is only invoked on integer solutions.

Attached I have added an export of my model, my param file and my mip start. When I load these into the interactive optimizer, everything works fine: the solution is correct. Note that the MIP start is already the optimal solution.

So in summary: my application works great without a MIP start, but whenever I add a MIP start, the lazy constraint callback is invoked on fractional solutions.

Suggestions are welcome.

Originally posted by: JorisK

I have tried fixing the variable lower and upper bounds to the values from my MIP start in my Java code. This indeed correctly returns the MIP start as optimal solution. Hence, I still don't know why the Lazy Callback is invoked on a fraction solution. Could this be a bug in cplex?

I'm afraid you have hit on a bug in CPLEX. As far as we can tell at this moment this bug occurs only if you provide a MIP start with the optimal solution.

Originally posted by: JorisK

Hm, that is rather inconvenient. Is this bug already resolved in the latest cplex version? I'm currently using cplex 12.4, but I wouldn't mind upgrading to the latest 12.5.

In my Lazy Callback implementation I could add a check to verify whether the solution is fractional or not. In case the solution is fractional, I would simply return, i.e. skip the remainder of the callback procedure. Otherwise (in case of an integer solution) I could proceed to separate violated inequalities as normal. Is this a good work around, or is this somehow dangerous?

Upgrading to 12.5 (and then to 12.5.0.1) is a good idea. I was not able to reproduce the problem with 12.5.0.1 and from our analysis it is highly unlikely that this bug is triggered in 12.5.0.1.

As for skipping over fractional solutions: I'm afraid that this is dangerous since you may unexpectedly accept solutions that should be rejected.

Originally posted by: revolt

Hi, I am using CPLEX 12.5.0.0 with the JAVA API.

I am also getting a lot of fractional solutions in LazyConstraintCallbacks even without providing any MIP Start. I assumed that this is normal behavior. In my model it only makes sense to add a lazy constraint if the LazyCkb solution is integral. For this reason my LazyCbk always contains a check that tells me whether the solution is integral or not. If it is, I add the cut. Otherwise I do nothing.

I am now wondering, whether my workaround is "save", i.e., it does not create undefined behavior?

(By the way, I don't like the new forum design :o)

EDIT: I just noticed that you already answered the question: "...I'm afraid that this is dangerous since you may unexpectedly accept solutions that should be rejected." For this reason I also implemented the IncumbentCbk to ensure that I do not accidentally accept an solution that violates my lazy constraints. So now I ask my question again: Is this a good workaround?

Nevertheless I should update to 12.5.0.1 and check whether I still get fractional solutions.

In conjunction with the incumbent callback I think your workaround is safe.

Are the solutions you get "very" fractional or is the fractionality so small that it could be numeric round-off? Would you be willing to provide an example SAV file that produces fractional solutions in the lazy constraint callback?

About the Forum design: I'm sorry about that but there is nothing we can do about it :-(

Originally posted by: revolt

As I assumed that this is normal behavior I did not jet check whether the solutions are "very" or "slightly" fractional. In the test instance that I am currently looking at the solutions are indeed only slightly fractional: e.g. 1.136E-13. But this was already enough to trigger my "integrality check". If I can be sure that the solution should be integral and is only slightly fractional then I would use another tolerance and simply polish the solution.

In a few days I will check whether there are "very" fractional solutions by running a test on all my instances. My CPU resources are currently used for another calculation.

Originally posted by: revolt

Now I ran about 300 instances and used a tolerance of 1e-6 and everything went well. There was no fractional solution that violated the 1e-6 tolerance. I should have checked this earlier... Now I did not need to "skip" any "slightliy" fractional solution.

Thanks for checking.

In any case, the lazy constraint callback should be only invoked for integral solutions. If there is a significant difference between value and Math.round(value) for integer variable then this is considered a bug. Small differences are always possible due to numeric round-off.