cvxpy icon indicating copy to clipboard operation
cvxpy copied to clipboard

Handling of Mosek's `Unknown` Problem Status

Open pqrz opened this issue 2 years ago • 7 comments

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.

pqrz avatar May 27 '22 04:05 pqrz

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.

SteveDiamond avatar May 27 '22 16:05 SteveDiamond

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.

erling-d-andersen avatar Jun 14 '22 11:06 erling-d-andersen

@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 avatar Aug 14 '22 00:08 rileyjmurray

@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.

aszekMosek avatar Aug 15 '22 08:08 aszekMosek

Thanks for the input @aszekMosek! I like that idea.

rileyjmurray avatar Aug 20 '22 20:08 rileyjmurray

I can add this.

Mojusko avatar Jan 23 '23 09:01 Mojusko

@Mojusko that would be a welcome contribution!

rileyjmurray avatar Jan 23 '23 14:01 rileyjmurray