Originally posted by: akazachk

Dear all,

I am relatively new to CPLEX, so I apologize in advance if I am making an obvious mistake somewhere. I appreciate any pointers in any case.

The problem attached to this post seems to be displaying some weird behavior. Namely, as shown in the attached log, with presolve on, CPLEX says that the problem is infeasible, and when presolve is off, an optimal solution is found. When presolve is on, the LP relaxation is detected as infeasible, with the message that "Implied bounds make row 'R0000098' infeasible." (This instance is formed by adding a round of Gomory cuts to the formulation of the miplib3 instance egout, and R0000098 is one of these cuts).

I am using CPLEX 12.7.1, and replicated this behavior on a Mac and a Linux machine.

Thank you in advance for your help,

Aleksandr Kazachkov

I reproduced this here. At first glance the numbers in your model look fine and this may be a bug in CPLEX. I am digging into it.

First of all, the modeling assistance tool shows some warnings for your model: some coefficients look as if they were computed only in single precision (but this may also be truncation of numbers when writing to MPS) and some rows could be scaled by small integers to obtain "cleaner" coefficients.

However, the problem persists even after fixing these warnings.

I am not yet sure whether to call this a bug in CPLEX or numerical trouble. The trouble comes from rows like this

R0000115: I.026027 + 0.0953288847 F....026 + 0.0953288847 F.024026 + 0.0953288847 F.025026 - 0.095328885 F.026027 >= 1

where you have coefficients like 0.0953288847 and 0.095328885 that differ only by 3e-10. These coefficients being almost equal eventually cause a presolve reduction to conclude infeasibility. Are these coefficients intended to be different? Or is this round-off error in the application that creates those coefficients? In the latter case, fixing this roundoff should help (maybe round the coefficients to N decimal places?).

Originally posted by: akazachk

Hi Daniel, it is indeed the latter case; these coefficients are supposed to be the same, only differing in sign. Ensuring that both positive and negative numbers have the same number of digits fixes the issue (presolve no longer detects infeasibility). The problem was from writing a model to an MPS file in which negative numbers received fewer significant digits.

The original instance I submitted, had it been correct, would probably qualify as "numerical trouble", though it may still be worth doing something about it (e.g., checking min delta between any coefficients in the modeling assistance tool).

Thank you for your help!

I have filed a user wish to have the modeling assistance tool warn about this situation.