Cbc
Cbc copied to clipboard
coin-or
Model using loadProblem is infeasible, but same problem using readMps is feasible
Using the C API, I've created this minimal example: loadModel.c.txt
Rename this to loadModel.c and build it with gcc -o loadModel loadModel.c -lCbcSolver
I load a problem using two methods: the first using loadProblem, which I then write to an mps file, and the second, by reading that just-written mps file.
The version using loadProblem is infeasible when preprocessing is turned off, and feasible when it is turned on. The mps version is feasible both ways.
This might be the same bug as #518 , but I can't test it because I can't build libCbcSolver.so (see #541 ).
I don't know much about the C interface. It seems to work with master. Fails with stable - but succeeds if maximization is turned off. I will try and see if it is something simple.
I was wrong - it is a serious error introduced when trying to improve printout when maximizing.
I'm confused. You say this is a serious error, but it's fixed already on master? If it's fixed, why would it matter?
Also, could you speak to #541? I'd really like to be able to root cause these issues myself if at all possible.
My mistake - my brain had gone mushy. I can get error with master and it is nothing to do with maximizing. I will update you tomorrow.
a) The reason the reading the mps file works is that is minimizing and the solution with 100 is feasible. When maximizing using the mps file the same problem occurs. b) The standard integer tolerance is 1.0e-6. With the values of 1.0e6 for coefficients and rhs in the model, the code gets confused about what is feasible and infeasible. So at root node, the code thinks it has a solution but then when it double checks it finds it has not - and the root node is treated as infeasible.
I tried adding code which if this happens the tolerance is changed to 1.0e-8 and the code tries again - then it does branch and gets correct solution. However if I change the coefficient values to 1.0e7 that fails.
In practice, my code uses -1e-6 instead of -.1 (I just reduced it to a minimal reproduction). I take it that means that's off the table?
I found that this works on both Gurobi and CPLEX if that matters.
Furthermore, using -3e-6 is infeasible, but -2e-6 is feasible with an optimum of 200, which is incorrect (it should be 100).
I retract my previous comment. I didn't realize I was minimizing. Only CPLEX succeeds with -1e-6. Gurobi gives an incorrect result at -1e-4 with a warning that its tolerances were exceeded.