Make Status enums clearer about highs

[jajhall]

Agreed, but we first need to consolidate three active branches that may conflict: DebugPresolve, HotStart and fortranif

[galabovaa]

Done.

[feldmeier]

I think HighsModelStatus still does at least two (maybe three) different things that should be split:

• The various Error-values are not "Modelstatus" (If a run was aborted due to e.g. presolve error, then Model Status should be "Not Set").
• REACHED_TIME_LIMIT, REACHED_DUAL_OBJECTIVE_VALUE_UPPER_BOUND etc are termination reasons, not a status of a model
• Primal feasible, unbounded etc are actual model status

[jajhall]

I don't agree that we should have more than one such status. OSL, CPLEX, Gurobi and Xpress all have a single status flag that carries information such as "not set", optimal, objective cut-off, timed out, iteration limit exceeded. Essentially they all feed back a single indication of "How far did the solver get?"

I did wonder about the name of the identifier in HiGHS

• OSL called it iprobstat

• CPLEX calls it CplexStatus

• gurobi calls it "status" within the "Model fields" of the struct returned by gurobi(model, params)

• Xpress calls it "LPSTAT" or "MIPSTAT" when solving MIPs

So I don't see a good reason to name it anything other than HighsModelStatus

[svigerske]

Two give more examples on the contrary:

• Mosek has a status to indicate why the solver stopped and each solution has a status that tells about its optimality/feasibility/infeasibility/etc.
• GAMS also has two status codes in a similar way. At the moment, in the GAMS/HiGHS interface, when HiGHS says it hit an iteration or time limit, I am not sure whether there is a solution and whether it is already primal feasible.

[odow]

JuMP has tree types of statuses:

Termination status: why did the solver stop?
http://www.juliaopt.org/MathOptInterface.jl/stable/apireference/#Termination-Status-1

And a primal status and a dual status: what is the status of the solution, if one exists?
http://www.juliaopt.org/MathOptInterface.jl/stable/apireference/#Result-Status-1

We put a lot of thought into the status reporting. We would highly recommend our approach over a single status enum.

[jajhall]

Thanks Oscar and Stefan, I'm trying to think of circumstances where HiGHS would need to express itself using two status values, particularly when solving continuous problems. Of it stops without determining optimality, infeasibility or unboundedness, then there's little that can be said about the solution. We will be returning information about number, max and sum of primal and dual infeasibilities, allowing primal or dual feasibility of the model to be deduced. Is it a serious gripe with users that Xpress, Cplex and Gurobi only return one status value?

[odow]

Is it a serious gripe with users that Xpress, Cplex and Gurobi only return one status value?

User's aren't usually aware of the issue. But it's a major pain for modeling packages like JuMP/GAMS.

The common cases are:

• A limit (time/iteration) was hit: do you have a solution to return? Returning TIME_LIMIT isn't sufficient to explain the state of the solution.
  A possible return triple is:
  • TerminationStatus: TIME_LIMIT
  • PrimalStatus: FEASIBLE_POINT
  • DualStatus: NO_SOLUTION
• The model was proved infeasible/unbounded: do you have a certificate to return? Returning INFEASIBLE isn't sufficient, because some solvers can prove infeasibility in presolve without a certificate.
  A possible return triple is:
  • TerminationStatus: INFEASIBLE
  • PrimalStatus: NO_SOLUTION
  • DualStatus: INFEASIBILITY_CERTIFICATE
• An optimal primal solution was found: do you have a dual solution to return? The solver may have found the optimal solution in primal presolve, and does not have a dual solution to return.
  A possible return triple is:
  • TerminationStatus: OPTIMAL
  • PrimalStatus: FEASIBLE_POINT
  • DualStatus: NO_SOLUTION

[jajhall]

Thanks. Put this way, Oscar make a fair point, raising an issue that I'd been thinking about. How to communicate whether the values in HighsSolution are meaningful, or not.

Other aspects of Oscar's needs will be satisfied when the number, max and sum of primal and dual infeasibilities are available - which is a matter of days away.

At the moment, only if a problem is solved to optimality are the values in HighsSolution meaningful.

When we start to be able to deduce a meaningful primal or dual solution when the problem is not solved to optimality, or start producing infeasibility certificates, there will be a case for making a PrimalStatus and DualStatus available in addition to our current ModelStatus.

None of this affects the return of "failure" information via ModelStatus.

[odow]

Although I'd have thought that if "The solver may have found the optimal solution in primal presolve, and does not have a dual solution to return." then DualStatus: NO_SOLUTION would be returned.

Oops. That's a typo. I've edited the comment.

[jajhall]

... which does act as an example of why I want to "keep things simple" at the moment. Thanks for the useful discussion, but there's a lot more to get right in HiGHS at the moment!