Catch SCIP errors / throw Python errors

[VonAlphaBisZulu]

PySCIPOpt's error management should be improved. There are many situations in which very simple problems resolve in uncaught errors and crash the parent python program.

Here is one simple example: Create an empty model, solve it, call freeReoptSolve, solve again.

from pyscipopt import Model

m = Model()
print('first optimization')
m.optimize()
print('change state')
m.freeReoptSolve()
print('state changed, 2nd optimization')
m.optimize()
print('done')

This goes into a segmentation fault that ends the Python thread. This should rather throw an error in Python with some more explanation on how to avoid it.

Just to be clear: I do not need help with the particular problem mentioned above. I just suggest catching errors and forwarding them to the python error stream.

[VonAlphaBisZulu]

Throwing the error in Python and showing the original error message would (1) help identify the problem (2) allow making use of Python debugging mode

[CGraczyk]

Hi, that does sound like a useful extension of the code! If you have a workaround for this issue or extended the code base on your side, please feel free to create a merge request and we can have a look to integrate this into the master.

Thanks for letting us know.

[VonAlphaBisZulu]

I wish I had, but unfortunately, I never dived deep enough into PySCIPOpt's code. Maybe someone can tag this issue as enhancement.

[VonAlphaBisZulu]

I'd really like to use SCIP 9.1.0, but I cannot because of this non-critical error in scip that writes to the error stream which stalls the parent program. Is there anything I can do about this?

[Joao-Dionisio]

Hey @VonAlphaBisZulu, there's a big conference going on, so it's going to be difficult helping out, but I'll try to see if anyone can. Sorry for this taking so long, it's actually a pretty important issue.

[Joao-Dionisio]

Hey, @VonAlphaBisZulu. Just checking, these are two different issues, right?

I understand the annoyance of programs crashing without an error message, but I think we can only solve this on a case-by-case basis. Maybe someone better at Cython can chime in eventually, but I spoke with a bunch of people, and none found a way to do it generally. These types of things probably happen because a PySCIPOpt function is missing a stage check, or it's not checking that the input is correct, or something like this. These are mostly easy fixes, and until a better way is found, we'll be solving them as users report them.

As for the ELEAVE56 error, did you check Issue #691? The problem here was that the user was trying to do column generation but he forgot to add modifiable=True to the constraints.

[VonAlphaBisZulu]

Thanks for the reply. I understand. It really seems like there is no easy fix to this. Perhaps it would be easier to resolve the issue in SCIP that I referenced before.

I checked issue #691 and modified my problem to have all constraints modifiable. It didn't fix it. The error refers to a constraint whose index higher than the number of constraints put into that problem. The issue might be that solving the MILP with SCIP introduces some cut-constraints that are not handled or passed on correctly to SoPlex. I think some cuts result in some variables being fixed to a certain integer value, and the constraint that does so is marked as "fixed". But then something, SCIP or SoPlex, tries to put them into the basis and fails because they are fixed. The error says, "this should never happen". This particular underlying problem should probably be addressed in SCIP.

[Joao-Dionisio]

Hello, @VonAlphaBisZulu! I think the problem with your initial code is that you didn't enable reoptimization. This code

m = Model()
m.enableReoptimization()
print('first optimization')
m.optimize()
print('change state')
m.freeReoptSolve()
print('state changed, 2nd optimization')
m.optimize()
print('done')

works for me. Admittedly, this should be better documented, but you can look at test_reopt.py. Does this also work in your work?

[VonAlphaBisZulu]

Hi Joao,

Yes, enabling reoptimization helps for this particular problem. The broader problem mentioned in the initial post is that errors (like ELEAVE56) were not caught properly. So they cannot be caught with "try-catch" in python, but they will stall or kill the parent Pyhton program instead. Admittedly, I haven't looked into this for a while and don't know if this has been resolved in the meantime.