Open GabrielPonte opened 2 years ago
@Wikunia @odow this looks like a reasonable extension to me. What do you think?
Possibly the MOI documentation makes SLOW_PROGRESS
sound more problematic that it really is?
Merging #248 (92340ac) into master (053661e) will decrease coverage by
0.04%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## master #248 +/- ##
==========================================
- Coverage 91.81% 91.76% -0.05%
==========================================
Files 20 20
Lines 2015 2015
==========================================
- Hits 1850 1849 -1
- Misses 165 166 +1
Impacted Files | Coverage Δ | |
---|---|---|
src/util.jl | 71.17% <100.00%> (ø) |
|
src/BnBTree.jl | 94.34% <0.00%> (-0.30%) |
:arrow_down: |
:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more
Yeah I don't know if you want Juniper to act as if SLOW_PROGRESS
is the same as optimal. It's really telling you that there is a problem with the model formulation, and so it should be fixed on the modeling side.
See this recent discourse post: https://discourse.julialang.org/t/adding-objective-to-jump-model-changes-feasibility/83200
This had the same underlying issue as https://github.com/lanl-ansi/Juniper.jl/pull/250. Now it should be fine because Juniper can return SLOW_PROGRESS
as the termination status, and RESULT_STATUS_UNKNOWN
for the primal status.
Claiming that SLOW_PROGRESS
is the same as optimal is the wrong thing to do.
When dealing with numerical problems, Mosek can return SLOW_PROGRESS in the termination status. Sometimes, in my experiments, the optimal solution wasn't reached because of this, maybe Juniper treats it as Infeasible, but not necessarily is an infeasible solution, most of the times is almost feasible solution or almost optimal solution. Links: https://docs.mosek.com/latest/capi/response-codes.html
https://groups.google.com/g/mosek/c/v7lbk__Gr4s
https://gitter.im/JuliaOpt/SumOfSquares.jl?at=5d02c3f12d3f89045fb6b444