I have a Benders decomposition application where the LP subproblem never generates optimality cuts, only feasibility cuts, and will be infeasible the vast majority of the times it is checked. So I go straight to the conflict refiner, and try to solve the LP only if the refineConflict method returns false.

Initially this worked fine, but now I am getting multiple warnings on stderr: "Infeasibility model not feasible; tightening tolerances." Am I correct in assuming that this is the conflict refiner saying that it failed to find a conflict and is going to reduce EpInt and EpRhs in an attempt to turn one up? If so, is there any way to tell the conflict refiner not to do this (and instead just return false if, with existing tolerances, it fails to find a conflict)? I looked in the parameter list but could not find anything.

I'm looking at a bug right now where I get a slightly suboptimal final solution, which I suspect means that the conflict refiner got too aggressive and generated a "conflict" that turned into a feasibility cut that lopped off the true optimum.

Thanks,

Paul
 

Originally posted by: TobiasAchterberg

The model that the conflict refiner for LPs constructs is taken from the paper of J. Gleeson and J. Ryan: "Identifying Minimally Infeasible Subsystems of Inequalities.  ORSA Journal on Computing Vol.2 N.1 61-63, 1990".

This model should always be feasible, also if applied to feasible LPs.

The warning that you get clearly points to a numerical issue: the model should be feasible, but when CPLEX tries to solve it it gets a solution status that is not equal to CPX_STAT_OPTIMAL.

Tobias

Thanks, Tobias. I had a feeling that was what was going on. The error message has inexplicably disappeared (same problem instance, no changes to the model that generated the error), so debugging it will be interesting.

I'm updating code that formerly used CPLEX 11.x (with getIIS rather than refineConflict). In that code we actually solved a version of the Gleeson-Ryan model, but with a slight relaxation (because the underlying LP is known to be numerically finicky, and there's nothing we can do about that).

One follow-up question: is there any way that I can get CPLEX to give up and either return an "unsolved" status or throw an exception that I can catch, rather than having it automatically tighten tolerances? Perhaps one of those hidden parameters I keep hearing about?

Thanks,

Paul