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

EAGO does not identify infeasbility of constraints in “easy” problem #112

Open
ankige opened this issue Nov 26, 2022 · 1 comment
Open

Comments

@ankige
Copy link

ankige commented Nov 26, 2022

Hi,

in the below problem I defined two constraints for which it is trivial to show analytically that they cannot be satisfied at the same time. However, the code takes lots of time and does not give back a clear unfeasibility certificate. Why is this? For other problems where I cannot show infeasibility analytically, the same code with other constraints works perfect.

Any help is appreciated.


using JuMP, EAGO
m = Model(EAGO.Optimizer)
# Define bounded variables
@variable(m, 10^(-6)<=c0<=10)
@variable(m, 10^(-6)<=c1<=10)
@variable(m, 1<=z0<=10)
@variable(m, 1<=z1<=10)
@variable(m, 10^(-6)<=v<=100)
# Define nonlinear constraints
@NLconstraint(m, e4, (18 * c1 - v^2 * (1 + z1 ) ) * (18 * c1 - v^2 * z1 ) <= -1 )
@NLconstraint(m, e5, (-18 * c1 + v^2 * (1 + z1 ))<= -1 )
# Define nonlinear objective
@NLobjective(m, Max, 0)
# Solve the optimization problem
optimize!(m)
@RXGottlieb
Copy link
Member

Hi,

We'll continue to look into it, but with this problem in particular, it looks like scaling may be a major issue. E.g., v spans 8 orders of magnitude (so v^2 spans 16 orders of magnitude), and if I check an interval extension of e4 I get [-1.98e+07, 1.1e+10], which is quite a wide search area. Infeasibility detection in the domain reduction phases will be poor as a result of this, so EAGO will rely on branch-and-bound to determine the infeasibility of all nodes, and it will need to do this until it exhausts the full stack. We do note that EAGO's interval constraint propagation method is currently inactive, which has been shown to be effective on some poorly-scaled problems. We intend to get this routine updated soon. For this problem in particular, if there is a way to rescale it, we expect that would likely do a lot to improve the solution speed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants