New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect PrimalStatus if termination is not optimal #249
Comments
A very good find! Kind of shocking this has been in the wild for so long without noticing. I don't know MOI well enough to suggest the best fix, but as long as the inner NLP solver returns a suitable "solved" status and all discrete variables are integral within the tolerance, we should mark the current incumbent as |
Taking a look now. |
I'm a bit confused by this to be honest. The fix in #250 doesn't change when |
Yeah, ideally the check in PrimalStatus would be about feasibility, not whether the optimal status has been found. But it's also okay to report feasible when you find the optimal solution and "I have no idea" if something else happened. That might be because the problem is infeasible, or it might be because of a time limit, and some other numerical issue. |
The |
Understood thanks for the explanation. |
Juniper reports the
PrimalStatus
asINFEASIBLE_POINT
when the problem is not optimal:Juniper.jl/src/MOI_wrapper/results.jl
Lines 29 to 39 in 053661e
This is incorrect, because sometimes the point is actually feasible. If we can prove feasibility, it should be
FEASIBLE_POINT
, otherwise it should be something likeUNKNOWN_RESULT_STATUS
First reported on Discourse:
https://discourse.julialang.org/t/obtaining-sub-optimal-results-from-the-model-when-the-time-limit-is-reached/85635
The text was updated successfully, but these errors were encountered: