Getting solutions when stage is not SOLVED

[tkoolen]

Currently, we have

https://github.com/SCIP-Interfaces/SCIP.jl/blob/7a5095fdbc10c4ccfd20d2a73f6df85015ce2ffc/src/MOI_wrapper/results.jl#L46

which is called in e.g.

https://github.com/SCIP-Interfaces/SCIP.jl/blob/7a5095fdbc10c4ccfd20d2a73f6df85015ce2ffc/src/MOI_wrapper/results.jl#L51-L54

However, SCIPgetBestSol allows SCIP to be in many more stages. Should the assert_solved check be changed to something less conservative? I'd change this straight away, but I'm not sure what requirements should be satisfied on the MathOptInterface side.

I ran into this when I tried to solve with a time limit; even though SCIP found a feasible point, the stage was still SOLVING, so I couldn't get the results.

[rschwarz]

Yes, I think it is overly conservative (or just simplified), although I also remember using more detailed assert_stage in other places.

Ideally, we could even extract the accepted stages from the C documentation in the comments, but I guess doing it manually is good enough for the dozen methods that are currently called.

Also, your example points to a nice test case that we could add!

In addition to checking the stage, it might also be wise to check whether a solution was found at all. I guess that C_NULL would be returned in that case, but the MOI.get should error, rather than return -1e20 or similar.

[bhalonen]

any progress/plans on this?

[rschwarz]

Yes, I actually relaxed the assertion already on two commits that are part of #109 which I hope to merge soon.

But both of these changes were done by the explicit need to call specific functions in specific stages, so there is no claim and full generality.

An alternative approach would be not check the stage at the SCIP.jl level, and instead try to handle SCIP's error better, as alluded in #78. Actually, this would be great, because it would always be up-to-date, automatically, without any code duplication.

[bhalonen]

This issue closed? Or can further guidance be given?

[rschwarz]

Well, the original use case (getting a solution when SCIP was interrupted by a user limit) is now handled by assert_solved, so yes.

But there are more stages where this could be valid, which are not covered. I'm not aware of all potential possibilities, though, so I would add either handle them when the need arises, or in some automatic fashion.

@bhalonen, do you have a use case example where an error is thrown because of overly strict assertions?

[rschwarz]

I will close this, until we find another case that is not handled by the current list of accpeted stages.