`max_wall_time` is still not working

[this-josh]

trafficstars

I've read issues #278 and #279, which suggest this should have been fixed in v0.9.0 but I'm finding in Ipopt.jl v1.0.3 this still not working, unless I'm doing something wrong?

julia> using JuMP, Ipopt;
julia> m = Model(Ipopt.Optimizer);
julia> @variable(m, 0 ≤ a ≤ 1);
julia> @objective(m, Min, a);
julia> set_optimizer_attribute(m, "max_wall_time", 1) # Int(1) gives the same output
julia> optimize!(m)
Tried to set Option: max_wall_time. It is a valid option, but it is of type  Number, not of type Integer. Please check the documentation for options.

### max_wall_time (Real Number)  ###
Category: Termination
Description: Maximum number of walltime clock seconds.
0 < (1e+20) <= +inf
ERROR: IPOPT: Couldn't set option 'max_wall_time' to value '1'.
Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:33
 [2] AddIpoptIntOption(prob::IpoptProblem, keyword::String, value::Int64)
   @ Ipopt ~/.julia/packages/Ipopt/rz6uf/src/C_wrapper.jl:355
 [3] optimize!(model::Ipopt.Optimizer)
   @ Ipopt ~/.julia/packages/Ipopt/rz6uf/src/MOI_wrapper.jl:1211
 [4] optimize!
   @ ~/.julia/packages/MathOptInterface/YQqin/src/Bridges/bridge_optimizer.jl:379 [inlined]
 [5] optimize!
   @ ~/.julia/packages/MathOptInterface/YQqin/src/MathOptInterface.jl:87 [inlined]
 [6] optimize!(m::MathOptInterface.Utilities.CachingOptimizer{MathOptInterface.Bridges.LazyBridgeOptimizer{Ipopt.Optimizer}, MathOptInterface.Utilities.UniversalFallback{MathOptInterface.Utilities.Model{Float64}}})
   @ MathOptInterface.Utilities ~/.julia/packages/MathOptInterface/YQqin/src/Utilities/cachingoptimizer.jl:316
 [7] optimize!(model::Model; ignore_optimize_hook::Bool, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ JuMP ~/.julia/packages/JuMP/Y4piv/src/optimizer_interface.jl:161
 [8] optimize!(model::Model)
   @ JuMP ~/.julia/packages/JuMP/Y4piv/src/optimizer_interface.jl:143
 [9] top-level scope
   @ REPL[6]:1
(tmp) pkg> st
      Status `/private/tmp/Project.toml`
  [b6b21f68] Ipopt v1.0.3
  [4076af6c] JuMP v1.1.1

While it cannot be demonstrated in this MWE this runs but also doesn't have a time limit set

set_time_limit_sec(m, 10)
optimize!(m)

[odow]

Looks like you need set_optimizer_attribute(m, "max_wall_time", 1.0). Ipopt uses different methods to set options, so we rely on the type passed by the user to infer which method to call. If you pass the wrong type, this error occurs.

[this-josh]

Thanks that works. The Ipopt docs say it must be an int, using an int sets it with the ipopt.jl function ipopt.AddIpoptIntOption, and the error message says it must be an int so it is quite confusing that the solution is to make it a float? Although, I appreciate that ipopt.jl has to infer what ipopt is after so I'm not sure how this situation could be improved.

Also, set_time_limit_sec(m, 20.0) doesn't work and doesn't give an error, I guess this may be a JuMP issue?

[odow]

The Ipopt docs say it must be an int

Where?

Also, set_time_limit_sec(m, 20.0) doesn't work and doesn't give an error

It sets the max_cpu_time attribute, because when the code was written, max_wall_time didn't exist: https://github.com/jump-dev/Ipopt.jl/blob/e5f978cc3e8212b27ee361e218356d33f785cb4e/src/MOI_wrapper.jl#L240-L254

[this-josh]

Sorry, I miss-read the docs and presumed the error message would be in agreement with the docs, it seems the docs don't specify any types. But the error message does state Int. I'm unsure on the aforementioned inference mechanism, but perhaps there could be a try: int; except: float kind of methodology? Providing a function an int, the c call then being inferred, and then receiving an error saying the function requires an int seems like a process which could be improved.

I see, I haven't previously set that attribute manually. However, in my experience set_time_limit_sec has no bearing on the run time of an ipopt model, I've set it to 20 and had ipopt run for over 600 seconds. Sorry I'm unsure on how to easily make a minimum working example of this

[odow]

My experience is to generally be against hacks like the try-catch, because it leads to small incompatibilities between Ipopt via MOI and Ipopt the C library. If you're using Ipopt, and you choose to set a solver-specific attribute like max_wall_time, there's a bit of overhead on the user to figure out the correct option.

Note that when you use the solver-independent option set_time_limit_sec we promote things automatically.