Skip to content

Commit

Permalink
Handle new CyLP statuses from coin-or/CyLP#150 (#1707)
Browse files Browse the repository at this point in the history
  • Loading branch information
@mkoeppe
mkoeppe authored Mar 15, 2022
1 parent a86ebf7 commit d390389
Showing 1 changed file with 3 additions and 0 deletions.
3 changes: 3 additions & 0 deletions cvxpy/reductions/solvers/conic_solvers/cbc_conif.py
View file
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,9 @@ class CBC(ConicSolver):
# Map of CBC status to CVXPY status.
STATUS_MAP_MIP = {'solution': s.OPTIMAL,
'relaxation infeasible': s.INFEASIBLE,
'problem proven infeasible': s.INFEASIBLE,
'relaxation abondoned': s.SOLVER_ERROR, # sic
'relaxation abandoned': s.SOLVER_ERROR,
'stopped on user event': s.SOLVER_ERROR,
'stopped on nodes': s.OPTIMAL_INACCURATE,
'stopped on gap': s.OPTIMAL_INACCURATE,
Expand Down

8 comments on commit d390389

@tkralphs
Copy link

@tkralphs tkralphs commented on d390389 Mar 15, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this looks basically correct. I guess you don't expect to allow for a customized code in which there could be a stoppage due to a user event? I might map stopped on user event to the same status as the other stopped on conditions. Maybe it just won't ever occur?

I'm also not sure what OPTIMAL_INACCURATE means. It seems to denote that there is a solution but that it may not be optimal. However, there may or may not be a solution when the algorithm is stopped early and the problem may or may not even be feasible. So this is seems like a slightly confusing name for whatever that status is intended to be. And depending on what it's intended to be, that mapping may or may not be correct.

@SteveDiamond
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

USER_LIMIT is the code for a stoppage due to a user event. OPTIMAL_INACCURATE means that the solution does not satisfy the specified (or default) solver tolerance, but satisfies some looser tolerance.

@mkoeppe
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, the Gurobi solver codes are mapped like this: https://github.com/cvxpy/cvxpy/blob/master/cvxpy/reductions/solvers/conic_solvers/gurobi_conif.py#L37

@tkralphs
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OPTIMAL_INACCURATE means that the solution does not satisfy the specified (or default) solver tolerance, but satisfies some looser tolerance.

Since you said "the solution", I assume this status means that a solution has been found, but not proven optimal. In this case, the mapping would not be correct, since a solution may or may not have been found when the algorithm is stopped on a limit. USER_LIMIT sounds like the right status for stopping on nodes or gap, but those are not exactly "user events," just user-specified resource limits. There actually isn't a status in Cbc that maps to OPTIMAL_INACCURATE.

The Gurobi map looks a bit funky. It maps stopping on time to USER_LIMIT, but stopping on nodes is an error. I guess if there is no way to set a node limit through the interface, then this should be an error. In that case, perhaps this is also the right mapping for CyLP.

@mkoeppe
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/cvxpy/cvxpy/blob/master/cvxpy/reductions/solvers/conic_solvers/gurobi_conif.py#L218 passes arbitrary solver parameters through to gurobipy

@tkralphs
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then it's a bit strange that stopping on nodes is considered an error. A number of things that are not really errors map to errors in the Gurobi interface, so this doesn't seem like a good model to go by. Even SUBOPTIMAL maps to an error when this seems to mean the same thing as OPTIMAL_INACCURATE.

@mkoeppe
Copy link
Contributor Author

@mkoeppe mkoeppe commented on d390389 Mar 16, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another data point: ortools linear_solver maps everything to ResultStatus https://github.com/google/or-tools/blob/stable/ortools/linear_solver/linear_solver.h#L433:

This is very clear, and the question is what should be the equivalent of FEASIBLE and NOT_SOLVED in terms of CVXPY solver constants - https://github.com/cvxpy/cvxpy/blob/master/cvxpy/settings.py#L48

@tkralphs
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the problem is that the statuses CVX makes available are the ones you would expect to see in a convex solver. MILP solvers are just fundamentally different and can terminate in ways that a convex solver would not. I don't think it's possible to have a clean mapping from the statuses of an MILP solver to the statuses of a convex solver. I would suggest to just have a separate list of statuses that apply only to MIILPs rather than an imperfect mapping to the existing statuses intended for convex problems.

Please sign in to comment.