Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to force primal/dual ray #1956

Closed
odow opened this issue Oct 2, 2024 · 6 comments
Closed

Option to force primal/dual ray #1956

odow opened this issue Oct 2, 2024 · 6 comments
Assignees
Labels
BE-JuMP enhancement New feature or request

Comments

@odow
Copy link
Collaborator

odow commented Oct 2, 2024

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
Copy link
Member

jajhall commented Oct 2, 2024

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?

@jajhall jajhall self-assigned this Oct 2, 2024
@jajhall jajhall added the enhancement New feature or request label Oct 2, 2024
@odow
Copy link
Collaborator Author

odow commented Oct 2, 2024

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
Copy link
Member

jajhall commented Oct 2, 2024

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
Copy link
Collaborator Author

odow commented Oct 2, 2024

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
Copy link
Member

jajhall commented Oct 2, 2024

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
Copy link
Member

jajhall commented Oct 27, 2024

Closed by #1984

@jajhall jajhall closed this as completed Oct 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BE-JuMP enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants