Question about requested features in a JuMP model

[Dominique Orban]

Hi,

Something's not clear to me about the features you can request from a JuMP model (:Grad, :Jac, etc.). I'm looking at the example at

http://www.juliaopt.org/JuMP.jl/0.14/nlp.html#querying-derivatives-from-a-jump-model

where only :Grad is requested. My understanding is that that means other features are simply not available, e.g., evaluating the Jacobian or Hessian. That seems to be correct regarding the Hessian:

julia> MathProgBase.hesslag_structure(d)
ERROR: Hessian computations were not requested on the call to MathProgBase.initialize.
 in hesslag_structure(::JuMP.NLPEvaluator) at /Users/dpo/.julia/v0.5/JuMP/src/nlp.jl:977

but JuMP seems happy trying to set up the Jacobian structure:

julia> MathProgBase.jac_structure(d)
 (Int64[],Int64[])

(the problem I link to above doesn't have constraints but the same happens with a constrained problem). In fact:

 julia> MathProgBase.features_available(d)
5-element Array{Symbol,1}:
 :Grad    
 :Jac      
 :ExprGraph
 :Hess    
 :HessVec

What am I missing?

Thanks!

[Miles Lubin]

It's not a bug if a feature is available even when you don't ask for it, it's just behavior that you shouldn't rely on. features_available is meant to be called before initialize to find out which features you're allowed to request. See the example in Ipopt: https://github.com/JuliaOpt/Ipopt.jl/blob/41b1e7010a2ed92e1f21cec7df6195b581d5707a/src/IpoptSolverInterface.jl#L38.

[Dominique Orban]

Thanks. I can see the logic behind the IPOPT example. I was interested in using the features the other way around. The model

https://github.com/JuliaSmoothOptimizers/OptimizationProblems.jl/blob/master/src/penalty2.jl

takes ages to "build" for large values of n (e.g., n=5000) if :Hess is in requested_features, but goes pretty fast if I only request :HessVec. I now realize that was not the intended purpose of the features?! If not, is there any interest in supporting such usage? It seems quite crucial to very large scale models that can't realistically be solved by factorization-based methods.

[Miles Lubin]

You can certainly avoid asking for Hess if you know that it's slow for a particular model. It looks like that model has a fully dense hessian, which JuMP hasn't been optimized for (we could skip the coloring step). (As an experiment you might try computing the full hessian by doing the n HessVec products.) We've had some discussions about being able to estimate the time it might take to compute a hessian with different methods, but at the moment there's no way for you to query a JuMP model to ask how expensive the hessian might be.

[Dominique Orban]

In fact I don't need the Hessian, only Hessian-vector products. So I'm happy if the Hessian coloring is skipped if I leave :Hess out of the requested features. Thanks.

[Miles Lubin]

So I'm happy if the Hessian coloring is skipped if I leave :Hess out of the requested features.

You may assume that is the case.