ERGO-Code / HiGHS

Linear optimization software
MIT License
992 stars 184 forks source link

Option to force primal/dual ray #1956

Closed odow closed 4 weeks ago

odow commented 1 month ago

One thing that would be useful is an option like https://www.gurobi.com/documentation/current/refman/infunbdinfo.html, which would force HiGHS to return a primal or dual unbounded ray.

Currently, if presolve is on, Highs_getDualRay can fail.

I'm updating JuMP's Benders tutorial, and I've had to hack at this by disabling presolve: https://github.com/jump-dev/JuMP.jl/pull/3833/files#diff-6594e4c942d86ae07c08096952141d68928e081a4118923c2332e75123742f2cR452

jajhall commented 1 month ago

Sure, although the situation isn't quite what Gurobi needs to resolve. If HiGHS presolve identifies that the LP is dual infeasible then the LP is (primal) infeasible or unbounded and, by default, HiGHS runs primal simplex to identify which holds, yielding a primal ray when the LP is primal unbounded. Gurobi doesn't do this by default, needing DualReductions to be 0 (off) so that dual infeasibility isn't found in presolve.

If the LP is dual infeasible, HiGHS doesn't find a primal ray when the LP is primal infeasible

If the LP is primal infeasible, HiGHS doesn't find a dual ray when this is identified in presolve, or when the LP is dual infeasible

Do you just want me to resolve the absence of a dual ray when primal infeasibility is identified in presolve?

Or do you feel that HiGHS should always offer a dual (primal) ray when the LP is primal (dual) infeasible, regardless of its dual (primal) infeasibility - ie full Farkas information?

odow commented 1 month ago

Do you just want me to resolve the absence of a dual ray when primal infeasibility is identified in presolve?

This would cover my needed use-case.

Or do you feel that HiGHS should always offer a dual (primal) ray when the LP is primal (dual) infeasible, regardless of its dual (primal) infeasibility - ie full Farkas information?

Could we just make this the behavior of Highs_getDualRay and Highs_getPrimalRay? I would assume that if the user is calling these, they really really want the ray, and they don't want some technical detail like you identified infeasibility in presolve to prevent returning the ray. It's okay if getXXXRay is not an O(1) lookup from existing values.

jajhall commented 1 month ago

So long as folk realise that if the ray's not already available then to find it could be a significant cost, then it's easy to add the code to calculate a Farkas ray in all cases

odow commented 1 month ago

if the ray's not already available then to find it could be a significant cost

Yeah. Maybe gate this behind an option? So Highs_getDualRay keeps the current behavior unless the user opts in with force_infeasibility_certificates = on?

jajhall commented 1 month ago

I'd rather leverage the current functionality, where users can query whether a ray is already available by passing nullptr for the ray data. If the user passes valid pointers, then it triggers the calculation if the ray is not already available

jajhall commented 4 weeks ago

Closed by #1984