MindtPy solver result status is always ok, inconsistent with other solvers
Summary
The solver status of the MindtPy SolverResults is always ok, regardless of whether the run succeeded or was infeasible.
Compare toy outputs:
# ----------------------------------------------------------
# Solver Information
# ----------------------------------------------------------
Solver:
- Name: MindtPyOA
Status: ok
Message: None
User time: 1.0085858640959486
Wallclock time: 1.0085858640959486
Termination condition: optimal
Termination message: None
Timing: Call after main solve: 1.582200638949871e-05
Call after subproblem solve: 7.261987775564194e-06
OA cut generation: 0.025928630027920008
fixed subproblem: 0.41343197599053383
initialization: 0.45735282404348254
main loop: 0.4906451030401513
main: 0.03497416106984019
main_timer_start_time: 533457.340001346
total: 1.0085858640959486
Iterations: 1
Num infeasible nlp subproblem: 0
Best solution found time: 0.9881699590478092
Primal integral: 0.0
Dual integral: 0.0
Primal dual gap integral: 0.0
# ----------------------------------------------------------
# Solver Information
# ----------------------------------------------------------
Solver:
- Name: MindtPyOA
Status: ok
Message: None
User time: 2.5718622769927606
Wallclock time: 2.5718622769927606
Termination condition: infeasible
Termination message: None
Timing: OA cut generation: 0.018135881051421165
initialization: 2.490958121023141
main loop: 0.026513111079111695
main: 0.025984823005273938
main_timer_start_time: 533459.609693973
total: 2.5718622769927606
Iterations: 1
Num infeasible nlp subproblem: 0
Best solution found time: None
Primal integral: nan
Dual integral: 0.0
Primal dual gap integral: nan
By contrast, other solvers return different statuses, and even solution information:
# ----------------------------------------------------------
# Solver Information
# ----------------------------------------------------------
Solver:
- Status: ok
Message: Ipopt 3.14.12\x3a Solved To Acceptable Level.
Termination condition: optimal
Id: 1
# ----------------------------------------------------------
# Solution Information
# ----------------------------------------------------------
Solution:
- number of solutions: 0
number of solutions displayed: 0
vs
# ----------------------------------------------------------
# Solver Information
# ----------------------------------------------------------
Solver:
- Status: warning
Message: Ipopt 3.14.12\x3a Maximum Number of Iterations Exceeded.
Termination condition: maxIterations
Id: 400
# ----------------------------------------------------------
# Solution Information
# ----------------------------------------------------------
Solution:
- number of solutions: 0
number of solutions displayed: 0
Is this intended behavior? Shouldn't the results object have some shared interface?
Information on your system
Pyomo version: … 6.5.0 - 6.6.1 Python version: 3.11 Solver (if applicable): MindtPy vs. others (ipopt/neos)
And here's a third pattern of SolverResults, from NEOS/Couenne:
# ==========================================================
# = Solver Results =
# ==========================================================
# ----------------------------------------------------------
# Problem Information
# ----------------------------------------------------------
Problem:
- Lower bound: -inf
Upper bound: inf
Number of objectives: 1
Number of constraints: 0
Number of variables: 0
Sense: unknown
# ----------------------------------------------------------
# Solver Information
# ----------------------------------------------------------
Solver:
- Status: warning
Message: infeasible
Termination condition: infeasible
Id: 200
Error rc: 0
Time: 0.38
Gap: 0.0
Primal bound: -1e+20
Dual bound: -1e+20
# ----------------------------------------------------------
# Solution Information
# ----------------------------------------------------------
Solution:
- number of solutions: 0
number of solutions displayed: 0
Thanks for pointing this out. You're correct in noting that the handling of the solver status in MindtPy is currently not optimal. At present, it would be more reliable to use the termination condition as a reference rather than the status. I will submit a PR to fix this as soon as possible.