-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
ELEAVE56 ERROR! Tried to put a fixed column variable into the basis #23
Comments
hi @VonAlphaBisZulu, I'm getting an error when trying to read in the file, could you write it as an MPS ? |
Hi, you find the problem here attached. I don't know why, but the LP-file solves with both 8.0.0 and 8.0.1, while the MPS shows infeasible in both. I created both, LP and MPS at the same breakpoint with the function scip.writeProblem. And the error I described earlier doesn't show. Something doesn't fit. I can reproduce my problem consistently. Not sure, how to share it correctly. |
Can you model the xor constraints as linear constraints x+y=1? Or will you have more complicated xor constraints in the future? |
@ambros-gleixner You're right, I will do this first. |
Updated LP and MPS. Same situation as in previous comment, but I also get the lines mentioned in my first post. So, you should be able to reproduce the problem. In SCIP throwing these errors might be okay, but with pyscipopt this leads to a crash. Should this issue be moved to pyscipopt? This is the output from SCIP 8.0.0
This is the output from SCIP 8.0.1
|
I know my problem has some variables fixed to zero, and hopefully this is not what causes the error. I fix and resolve to generate alternative solutions. I understand that removing the variables would be better practice, but I still feel that this should not throw an error (and neither does SCIP 8.0.0, CPLEX or Gurobi). |
Of course, this fixing and unfixing should work. So if this happens only through PySCIPOpt, can you provide a PySCIPOpt log? Does it abort after the first ELEAVE message? |
Okay, this is the full output when I run my code in Python on verbosity level 4. On the last line, it just stalls out. Nothing happens after this point, and I have to interrupt. A CI pipeline of mine on Github, which uses PySCIPOpt, throws a sefault. Not sure after how much time. I am uncertain if PySCIPOpt contributes anything to this output:
|
For completeness the output of SCIP 8.0.0
|
Thanks a lot, I confirm I can reproduce this with the LP file (the error does not appear with the MPS on my side) |
However, I have to say that PySCIPOpt does a terrible job at catching errors. Virtually every bit from SCIP that goes into the error stream kills your Python program, which makes debugging very tedious. The PySCIPOpt documentation is minimalistic and adds only very little to the SCIP docs. |
Sorry, for completeness:
What is the "expected" status for this problem? |
Optimal (minimal) with value 3 (just take the solution of SCIP 8.0.0 if unsure)
|
Thanks! |
hi @VonAlphaBisZulu, SCIP 8.0.2 was released so I rechecked your issue, it seems that the LP file always finds a solution for me. The MPS I now have a consistent failure for some reason. Can you check whether v8.0.2 fixed your issue? |
SCIP 8.0.2 did not fix my issue: For completeness, again the zip:
Procedure to solve these:
Solving yields:
|
I get a different behavior and am wondering what could lead to this. |
I tested on, Windows 11 and WSL2 with Ubuntu 20.04. In both cases, I installed scip through conda, simply with the command: Headers are in Windows (with python 3.7.12):
In WSL (with python 3.9.13):
Results in terms of errors and optimal values are identical in Windows and Linux for me. |
ok interesting, in debug mode I systematically get
no matter the version |
I'll check now what I get in release mode, it might be that the assert removed leads to something incorrect |
this is a tough one, for a bit of swapping through version combinations, it seems the culprit for the warning is the new soplex version, not the new SCIP. But it also seems that additional checks in debug modes were always throwing an error for the MPS, both for v800 and v802 |
As a mere user, I am not familiar with the SCIP code and building process. Just to express my thoughts: "ELEAVE56 ERROR! Tried to put a fixed column variable into the basis." should be caught and, if anything, raise a warning. The user has no way to avoid this, and when solving the identical problem from an LP-file, the solver continues after ELEAVE56. I'm sure you'll come up with a good solution. |
Should I create an issue in the SoPlex repo? |
Yes I agree that something should be caught by the solver, what it is exactly is still unclear to me. |
no need, I think something should be handled on the SCIP side in any case |
the question the last point raises is whether the problem in the MPS is well-formed, in which case it is the model construction part that is at fault |
@VonAlphaBisZulu the issue is solved with the LP file it seems, the MPS still causes the same issue, when using 8.0.3 |
Hello everyone! I am having the same issue but I couldn't understand If you had found a solution. Any help is welcomed |
@cjrodriguez98 This problem has not been fixed yet (SCIP 8.1) |
Hey! Just checking if any progress here o could we help in any way? |
I think that problem persists. Is there anything we can do to help you, to fix it @matbesancon and @ambros-gleixner? Unfortunately, some applications rely on indicator constraints and this makes it impossible to use SCIP for those. |
thanks for pinging us back on this, I assigned @leoneifler who is working on LP solving |
Has there been any progress on this topic @leoneifler? |
I did a bit more digging. It seems like this error is a SoPlex exception. The SoPlex error thrown literally says, "This should never happen". My guess is that SCIP fixes some branched binary variables and then attempts to put them in the basis for LP-solving with SoPlex. I am not familiar with the SCIP-SoPlex-interface and don't have all the debugging set up; so I haven't attempted to resolve this myself. I wasn't able to find any parameters that allow me to avoid the problem. |
@Joao-Dionisio says we have to resolve this issue now, because we cannot use waiting for Leon as excuse anymore. I tried to enable some debug output from SoPlex.
Here is the backtrace:
@ambros-gleixner Is that something that helps to see where things went wrong? Even though there is this exception thrown, the message printed, and SoPlex aborting the solve, SCIP seems to be able to recover and continue solving:
I get 3 as optimal value, the same I get with SCIP using CPLEX. |
But for related instances like this does not terminate after
for the current bugfix version
as mentioned in #23 (comment) as well, which might be the crucial aspect here. |
Thank you for taking care of it! |
Building a certain MILP with indicator constraints produces the following the lines of error and causes the program to crash:
The underlying issue was introduced between scip version 8.0.0 to 8.0.1 (scip 8.0.0 solves the problem correctly, scip 8.0.1 produces the error).
I use pyscipopt in python 3.7 to construct the problem. Both, version 4.2.0 and 4.0.0 work fine.
Here the "writeProblem" output (identical for scip 8.0.0 and 8.0.1):
The text was updated successfully, but these errors were encountered: