LP error not reproductible

[Thiago-NovaesB]

When I try to solve an LP using SCIP in my application, the solver returns SCIP_LPERROR. However, when I write the problem in .lp or .mps and use the same settings, scip solves the problem.
Do you have any idea what the difference would be between these executions? Maybe the numbers in memory in my application are slightly different from those written in the file and it is a numerical problem?
I am attaching the .lp, .mps and all non-default parameters. This occurred in 8.1 and 9.1.

params.txt
LP.it1.lp.txt

[Thiago-NovaesB]

There is a way to export the scip problem as binary?

[ambros-gleixner]

Hi Thiago, reasons can be both that numbers are slightly different (as you said), or that the order in which variables and constraints are represented in the lp file is different. There is no binary export of SCIP's state, unfortunately.

To help you further, maybe you can post SCIP's log output with highest verblevel here. For even more output, you can set display/lpinfo to TRUE, but that can create very long log files that are hard to parse.

[Thiago-NovaesB]

Hello, thank you for your help. I used:

"display/verblevel" = 5
"timing/statistictiming" = true
"display/lpinfo" = true

But it's looks like scip dont write lpinfo in the file, just in the console. Can you understand the problem with this log?

LP Solver <Soplex 7.1.0>: barrier convergence tolerance cannot be set -- tolerance of SCIP and LP solver may differ
LP Solver <Soplex 7.1.0>: fastmip setting not available -- SCIP parameter has no effect
LP Solver <Soplex 7.1.0>: number of threads settings not available -- SCIP parameter has no effect
transformed problem has 4172 variables (0 bin, 0 int, 0 impl, 4172 cont) and 4042 constraints
   4042 constraints of type <linear>

original problem has 30791 active (0.182593%) nonzeros and 30791 (0.182593%) check nonzeros

presolving:
(round 1, fast)       1424 del vars, 1448 del conss, 0 add conss, 1640 chg bounds, 0 chg sides, 0 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 2, fast)       1647 del vars, 1673 del conss, 0 add conss, 1862 chg bounds, 0 chg sides, 0 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 3, fast)       1678 del vars, 1704 del conss, 0 add conss, 1862 chg bounds, 0 chg sides, 0 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 4, exhaustive) 1678 del vars, 1779 del conss, 0 add conss, 1862 chg bounds, 0 chg sides, 0 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 5, fast)       1697 del vars, 1798 del conss, 0 add conss, 1864 chg bounds, 0 chg sides, 0 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 6, exhaustive) 1731 del vars, 1798 del conss, 0 add conss, 1864 chg bounds, 0 chg sides, 0 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
   (0.0s) sparsify finished: 2343/24489 (9.6%) nonzeros canceled - in total 2343 canceled nonzeros, 3894 changed coefficients, 0 added nonzeros
(round 7, exhaustive) 1732 del vars, 1799 del conss, 0 add conss, 1864 chg bounds, 0 chg sides, 3894 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 8, fast)       2032 del vars, 2099 del conss, 0 add conss, 2309 chg bounds, 0 chg sides, 3894 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 9, fast)       2050 del vars, 2118 del conss, 0 add conss, 2330 chg bounds, 0 chg sides, 3894 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 10, exhaustive) 2052 del vars, 2119 del conss, 0 add conss, 2330 chg bounds, 0 chg sides, 3894 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
   (0.0s) dualsparsify: 4060 nonzeros canceled
(round 11, exhaustive) 2052 del vars, 2119 del conss, 0 add conss, 2330 chg bounds, 0 chg sides, 11065 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 12, fast)       2114 del vars, 2181 del conss, 0 add conss, 2342 chg bounds, 0 chg sides, 11065 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
   (0.0s) dualsparsify: 129 nonzeros canceled
(round 13, exhaustive) 2114 del vars, 2181 del conss, 0 add conss, 2342 chg bounds, 0 chg sides, 11393 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 14, fast)       2124 del vars, 2191 del conss, 0 add conss, 2342 chg bounds, 0 chg sides, 11393 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
   (0.0s) dualsparsify: 2 nonzeros canceled
   (0.0s) symmetry computation started: requiring (bin +, int +, cont +), (fixed: bin -, int -, cont -)
   (0.0s) symmetry computation finished: 16 generators found (max: 1500, log10 of symmetry group size: 0.0) (symcode time: 0.00)
dynamic symmetry handling statistics:
   orbitopal reduction:       no components
   orbital reduction:         no components
   lexicographic reduction:   no permutations
handled 12 out of 12 symmetry components
(round 15, exhaustive) 2124 del vars, 2191 del conss, 16 add conss, 2342 chg bounds, 0 chg sides, 11399 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 16, fast)       2124 del vars, 2193 del conss, 16 add conss, 2344 chg bounds, 0 chg sides, 11399 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
   (0.0s) sparsify finished: 7/16380 (0.0%) nonzeros canceled - in total 2350 canceled nonzeros, 3912 changed coefficients, 0 added nonzeros
clique table cleanup detected 0 bound changes

presolved problem has 16373 active (0.427292%) nonzeros and 16373 (0.427292%) check nonzeros

presolving (17 rounds: 17 fast, 8 medium, 8 exhaustive):
 2124 deleted vars, 2193 deleted constraints, 16 added constraints, 2344 tightened bounds, 0 added holes, 0 changed sides, 11417 changed coefficients
 0 implications, 0 cliques
presolved problem has 2048 variables (0 bin, 0 int, 0 impl, 2048 cont) and 1871 constraints
   1871 constraints of type <linear>
Presolving Time: 0.00

(node 1) solution of LP 1 not optimal (pfeas=0, dfeas=0) -- solving again with tighter feasibility tolerance
(node 1) numerical troubles in LP 2 -- unresolved
(node 1) unresolved numerical troubles in LP 2 -- using pseudo solution instead (loop 1)
(node 1) forcing the solution of an LP (last LP 2)...
(node 1) solution of LP 2 not optimal (pfeas=0, dfeas=1) -- solving again with tighter feasibility tolerance
(node 1) solution of LP 2 not optimal (pfeas=0, dfeas=1) -- solving again from scratch
(node 1) numerical troubles in LP 3 -- unresolved

[ambros-gleixner]

It would be instructive to see also the log output of the console.

Generally, I note that

1. this is an LP. What is the motivation of using SCIP, and not an LP solver? With SCIP you will not have access to dual information.
2. There are no bounds on your variables. Could you set some?

[DominikKamp]

It is usually hard to reproduce LP results from scratch also due to internal numerical deviations up to a warm start. Enabling PaPILO (presolving/milp/maxrounds = -1) works around this issue. But the LP indeed looks numerically troublesome for example because there are multiple coefficients of magnitude 1e-9.

[Thiago-NovaesB]

We are using SCIP because this problem can be an LP or MIP, depending on the settings. I can't find in the documentation how to change the LP solver. I saw that there is an interface for CLP, but I can't find an example of how to use it. Do you have a reference to an example or could you explain how to do this?

[Thiago-NovaesB]

I'm using presolving/milp/maxrounds = 0 because -> #86
Do you have any update about that?

[DominikKamp]

Indeed, your instance motivated some fixes on modification of it using MIP-DD, however the original version is still not resolved.

[ambros-gleixner]

We are using SCIP because this problem can be an LP or MIP, depending on the settings. I can't find in the documentation how to change the LP solver. I saw that there is an interface for CLP, but I can't find an example of how to use it. Do you have a reference to an example or could you explain how to do this?

We don't provide binaries with other LP solvers, but https://scipopt.org/doc/html/md_INSTALL.php explains how to build with other LP solvers via LPS.

[DominikKamp]

SoPlex solves the instance, so it rather seems like SCIP does not trust the numerics of the problem and rather gives up instead of saying something wrong, meaning that the error messages are correct here.

The rounded exact solution is

LP.it1.txt

which is rejected

  [linear] <Er_2055391561>:  -<Er_n579376791>[C] (+1.03539766e+10) +119659932<Bl_1831961354>[C] (+0) +135920918<Bl_87901384>[C] (+0) +14710179.5<Bl_n869605024>[C] (+0) +230729638<Bl_n399663013>[C] (+40.998874) +49709355.8<Bl_n267266578>[C] (+17.9910046) +170883308<Bl_n48990912>[C] (+0) == 0;
;
violation: left hand side is violated by 1.08480453491211e-05
all 1 solutions given by solution candidate storage are infeasible

because the coefficients are too large.

So instead of replacing the LP solver, I recommend to either rescale the constraints, relax the feasibility tolerance (numerics/feastol = 1e-5 works here), or try exact-SCIP (branch exact-rational with setting exact/enabled = TRUE) if you really need a precise solution.