-
Notifications
You must be signed in to change notification settings - Fork 46
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
LD_SLSQP does not terminate on NaN #31
Comments
Does the |
Yep, that one works great. MWE: using JuMP, NLopt
m = Model(solver=NLoptSolver(algorithm=:LD_MMA)) # or :LD_SLSQP
@defVar(m, c >= 0)
@setNLObjective(m, Min, sqrt(c))
solve(m) Edit: also, using JuMP, NLopt
m = Model(solver=NLoptSolver(algorithm=:LD_MMA))
@defVar(m, 0 <= c <= 1)
@setNLObjective(m, Max, sqrt(c))
solve(m) |
What does "MWE" mean? |
Minimal working example, sorry. |
The hang is apparently inside JuMP code, but doesn't occur when another solver like Ipopt is used. Pretty strange. |
It's not hanging, it's just iterating without converging. |
Which part is iterating? |
NLopt |
What are the termination criteria? I don't see any tolerances. |
Just confirming that this is still a problem using JuMP
import NLopt
m = Model(NLopt.Optimizer)
set_optimizer_attribute(m, "algorithm", :LD_SLSQP)
@variable(m, c[1:2] >= 0)
@constraint(m, sum(c) <= 2)
@NLobjective(m, Max, (c[1] + 0.7*c[2])^0.5 - (0.7*c[2])^0.5 + (c[2] + 0.7*c[1])^0.5 - (0.7*c[1])^0.5)
optimize!(m) Although you could set time limits or tolerances to exit earlier: julia> using JuMP
julia> import NLopt
julia> m = Model(NLopt.Optimizer)
A JuMP Model
Feasibility problem with:
Variables: 0
Model mode: AUTOMATIC
CachingOptimizer state: EMPTY_OPTIMIZER
Solver name: NLopt
julia> set_optimizer_attribute(m, "algorithm", :LD_SLSQP)
julia> set_optimizer_attribute(m, "maxtime", 3.0)
julia> @variable(m, c[1:2] >= 0, start = 0)
2-element Vector{VariableRef}:
c[1]
c[2]
julia> @constraint(m, sum(c) <= 2)
c[1] + c[2] ≤ 2.0
julia> @NLobjective(m, Max, (c[1] + 0.7*c[2])^0.5 - (0.7*c[2])^0.5 + (c[2] + 0.7*c[1])^0.5 - (0.7*c[1])^0.5)
julia> @time optimize!(m)
3.005593 seconds (14.77 M allocations: 676.120 MiB, 4.12% gc time, 0.18% compilation time)
julia> termination_status(m)
TIME_LIMIT::TerminationStatusCode = 12 |
So the issue is that the derivatives aren't defined at the default starting point of It seems like for this algorithm NLopt just lets NaN accumulate and doesn't error. Should it? Or are there some algorithms that support NaN and can recover? |
g_ineq
when called from JuMP
@stevengj I'd appreciate your feedback on this issue. What is the expected behavior when functions or gradients return I bumped into this during https://github.com/JuliaOpt/NLopt.jl/pull/239/files#diff-1c91bbf6e133c9ebca6c69381a02bb628595d0216a3a095e281ddba57d495b9cR236-R237 |
It seems like this is a known issue with some algorithms. stevengj/nlopt#38 But it is intended behavior for others: stevengj/nlopt#279 (comment) So perhaps we just close this issue and deal with the consequences. No one else has come along to comment in nearly 10 years. |
The conclusion of the monthly developer call is that we should close this issue because it is nearly 10 years old, and because it is a "feature" of the upstream library. We shouldn't intercept |
This hangs for a while, and when I manually exit, I get
cc @mlubin
The text was updated successfully, but these errors were encountered: