Closed odow closed 4 weeks 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?
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.
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
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
?
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
Closed by #1984
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