cvxpy
cvxpy copied to clipboard
Handling of Mosek's `Unknown` Problem Status
We run large scale optimisation problems using Cvxpy + Mosek regularly.
One of our optimisation problems yielded problem status
and solution status
as Unknown, and Cvxpy returned solver error for same (instead of returning unknown
status).
In our case, we found - Mosek was able to correctly find optimal objective and optimal decision variables (since it matched with Cvxpy+Gurobi results - which returned optimal status
), but we are not sure if this will always be the case.
Ideally, if Mosek is able to return some (not necessarily optimal) objective and decision variables - we would expect the same with Cvxpy (rather than solver error).
This can be resolved if Cvxpy adds unknown
status in its STATUS_MAP Dictionary and SOLUTION_PRESENT list.
I ran into the same issue and monkey patched cvxpy with exactly the fix you proposed. If we wanted to add this change to cvxpy, I think we should introduce an UNKNOWN status in cvxpy.settings
. I'm not comfortable labeling it optimal_inaccurate
, because sometimes UNKNOWN in mosek does correspond to quite wrong values.
A solution with a status of unknown can be anything from arbitrary junk to a for-all practical purpose good enough solution.
For instance, if Mosek runs out of space during setup it will say unknown.
@SteveDiamond @erling-d-andersen what do you think about not changing the status code and just always attempting to propagate MOSEK's solution back through the solving chain? We could introduce a new type of SolverError
where the exception isn't raised until all variables are populated.
@rileyjmurray I would just comment that it must be some approach that makes the user painfully aware that what they are getting is in the category "this could be arbitrarily bad". Otherwise users will be fetching that solution (or, even worse, "solution") and using it without checking anything.
In Fusion we ask the user to call an explicit method to confirm they want to receive solutions other than optimal. An equivalent of that in cvxpy would be some extra explicit argument like
prob.solve(..., want_suspicious_solutions=True)
so that there can be absolutely no doubt one gets what one asked for.
Thanks for the input @aszekMosek! I like that idea.
I can add this.
@Mojusko that would be a welcome contribution!