Scip Generates Inconsistent Solutions With Non-default Parameters
Introduction
SCIP is a widely used open-source software for mixed-integer linear programming (MILP) and other combinatorial optimization problems. However, like any other software, SCIP is not immune to bugs and inconsistencies. In this article, we will investigate a specific issue where SCIP generates inconsistent solutions when using non-default parameters.
Background
The issue at hand was reported for a specific problem instance, seed.lp.txt, which can be found on GitHub. The problem instance is a MILP problem with 6 variables and 46 constraints. When solving this problem using SCIP with default parameters, the software returns the correct optimal solution with an objective value of -43484... However, when additional non-default parameters are set, specifically numerics/epsilon = 1e-9 and numerics/sumepsilon = 1e-9, SCIP returns an incorrect solution with an objective value of -43477...
Investigation
To investigate this issue, we need to understand the parameters involved and their effects on the solution process. The two non-default parameters in question are:
numerics/epsilon: This parameter controls the tolerance for the solution process. A smaller value means a more precise solution, but it also increases the computational time.numerics/sumepsilon: This parameter controls the tolerance for the sum of the variables. A smaller value means a more precise solution, but it also increases the computational time.
When these parameters are set to 1e-9, SCIP returns an incorrect solution. This suggests that the solution process is sensitive to these parameters, and a small change in their values can lead to a different solution.
SCIP Output
To better understand the issue, let's take a closer look at the SCIP output when the non-default parameters are set:
{{content}}gt; cat options.set
numerics/feastol = 1e-9
numerics/epsilon = 1e-9
numerics/sumepsilon = 1e-9
{{content}}gt;
{{content}}gt;
{{content}}gt; scip -f seed.lp -s options.set
SCIP version 10.0.0 [precision: 8 byte] [memory: block] [mode: debug] [LP solver: SoPlex 8.0.0] [GitHash: 1b1bc790f6]
Copyright (c) 2002-2025 Zuse Institute Berlin (ZIB)
External libraries:
SoPlex 8.0.0 Linear programming solver developed at Zuse Institute Berlin (soplex.zib.de) [GitHash: 85549f2c]
CppAD 20180000.0 Algorithmic Differentiation of C++ algorithms developed by B. Bell (github.com/coin-or/CppAD)
ZLIB 1.2.11 General purpose compression library by J. Gailly and M. Adler (zlib.net)
TinyCThread 1.2 small portable implementation of the C11 threads API (tinycthread.github.io)
GMP 6.2.1 GNU Multiple Precision Arithmetic Library developed by T. Granlund (gmplib.org)
AMPL/MP 4.0.0 AMPL .nl file reader library (github.compl/mp)
Nauty 2.8.8 Computing Graph Automorphism Groups by Brendan D. McKay (users.cecs.anu.edu.au/~bdm/nauty)
sassy 2.0 Symmetry preprocessor by Markus Anders (github.com/markusa4/sassy)
reading user parameter file <options.set>
read problem <seed.lp>
============
original problem has 6 variables (0 bin, 4 int, 2 cont) and 46 constraints
solve problem
=============
presolving:
(round 1, fast) 0 del vars, 0 del conss, 0 add conss, 1 chg bounds, 0 chg sides, 0 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(0.0s) symmetry computation started: requiring (bin +, int +, cont +), (fixed: bin -, int -, cont -)
(0.0s) no symmetry present (symcode time: 0.00)
presolving (2 rounds: 2 fast, 1 medium, 1 exhaustive):
0 deleted vars, 0 deleted constraints, 0 added constraints, 1 tightened bounds, 0 added holes, 0 changed sides, 0 changed coefficients
0 implications, 0 cliques
presolved problem has 6 variables (0 bin, 4 int, 2 cont) and 46 constraints
presolved problem has 0 implied integral variables (0 bin, 0 int, 0 cont)
46 constraints of type <linear>
Presolving Time: 0.00
time | node | left |LP iter|LP it/n|mem/heur|mdpt |vars |cons |rows |cuts |sepa|confs|strbr| dualbound | primalbound | gap | compl.
0.0s| 1 | 0 | 7 | - | 848k | 0 | 6 | 46 | 46 | 0 | 0 | 0 | 0 |-4.353170e+04 | -- | Inf | unknown
r 0.0s| 1 | 0 | 7 | - |randroun| 0 | 6 | 46 | 46 | 0 | 0 | 0 | 0 |-4.353170e+04 |-4.347703e+04 | 0.13%| unknown
0.0s| 1 | 0 | 8 | - | 905k | 0 | 6 | 46 | 47 | 1 | 1 | 0 | 0 |-4.349725e+04 |-4.347703e+04 | 0.05%| unknown
0.0s| 1 | 0 | 8 | - | 906k | 0 | 6 | 46 | 47 | 1 | 1 | 0 | 0 |-4.349725e+04 |-4.347703e+04 | 0.05%| unknown
0.0s| 1 | 0 | 8 | - | 906k | 0 | 6 46 | 46 | 1 | 1 | 0 | 0 |-4.349725e+04 |-4.347703e+04 | 0.05%| unknown
0.0s| 1 | 0 | 9 | - | 906k | 0 | 6 | 46 | 46 | 2 | 2 | 0 | 0 |-4.347703e+04 |-4.347703e+04 | 0.00%| unknown
0.0s| 1 | 0 | 9 | - | 906k | 0 | 6 | 46 | 46 | 2 | 2 | 0 | 0 |-4.347703e+04 |-4.347703e+04 | 0.00%| unknown
SCIP Status : problem is solved [optimal solution found]
Solving Time (sec) : 0.02
Solving Nodes : 1
Primal Bound : -4.34770302451599e+04 (3 solutions)
Dual Bound : -4.34770302451599e+04
Gap : 0.00 %
primal solution (original space):
=================================
objective value: -43477.0302451599
x2 -79 (obj:-35.61)
x3 12 (obj:-67.04)
x4 -48 (obj:94.3)
x5 200 (obj:-60.18)
x1 -200 (obj:99.05)
x0 -190.655653664432 (obj:47.8)
The SCIP output shows that the problem is solved with an optimal solution, but the objective value is incorrect. This suggests that the solution process is sensitive to the non-default parameters, and a small change in their values can lead to a different solution.
Conclusion
In conclusion, the issue of inconsistent solutions with non-default parameters in SCIP is a complex problem that requires further investigation. The SCIP output suggests that the solution process is sensitive to the non-default parameters, and a small change in their values can lead to a different solution. To resolve this issue, it is essential to understand the parameters involved and their effects on the solution process. Additionally, it may be necessary to modify the SCIP code to handle non-default parameters more robustly.
Recommendations
Based on the investigation, the following recommendations are made:
- Use default parameters: When possible, use default parameters to avoid
Q&A: Inconsistent Solutions with Non-Default Parameters in SCIP ====================================================================
Q: What is the issue with non-default parameters in SCIP?
A: The issue is that SCIP generates inconsistent solutions when using non-default parameters. Specifically, when setting numerics/epsilon = 1e-9 and numerics/sumepsilon = 1e-9, SCIP returns an incorrect solution with an objective value of -43477...
Q: What are the non-default parameters involved in this issue?
A: The two non-default parameters involved are:
numerics/epsilon: This parameter controls the tolerance for the solution process. A smaller value means a more precise solution, but it also increases the computational time.numerics/sumepsilon: This parameter controls the tolerance for the sum of the variables. A smaller value means a more precise solution, but it also increases the computational time.
Q: What is the effect of these non-default parameters on the solution process?
A: The non-default parameters have a significant effect on the solution process. When these parameters are set to 1e-9, SCIP returns an incorrect solution. This suggests that the solution process is sensitive to these parameters, and a small change in their values can lead to a different solution.
Q: What is the SCIP output when the non-default parameters are set?
A: The SCIP output shows that the problem is solved with an optimal solution, but the objective value is incorrect. This suggests that the solution process is sensitive to the non-default parameters, and a small change in their values can lead to a different solution.
Q: How can I resolve this issue?
A: To resolve this issue, it is essential to understand the parameters involved and their effects on the solution process. Additionally, it may be necessary to modify the SCIP code to handle non-default parameters more robustly.
Q: What are the recommendations for resolving this issue?
A: Based on the investigation, the following recommendations are made:
- Use default parameters: When possible, use default parameters to avoid the issue.
- Modify the SCIP code: Modify the SCIP code to handle non-default parameters more robustly.
- Test the solution process: Test the solution process with different non-default parameters to ensure that the solution is correct.
Q: Is this a new issue?
A: This issue may not be new, and it is possible that it has been reported before. However, the investigation has provided new insights into the issue, and it is essential to understand the parameters involved and their effects on the solution process.
Q: How can I report this issue?
A: If you have encountered this issue, you can report it to the SCIP developers. Provide as much information as possible, including the SCIP output and the non-default parameters used. This will help the developers to understand the issue and provide a solution.