Zero length gradient passed to target (local_optimizer!) about nlopt.jl

[mlubin]

@feju, you can call local_optimizer! on m.opt where m is an NLoptMathProgModel object after calling loadnonlinearproblem!. Also happy to accept a PR to expose this through the standard MathProgBase solver options format.

Regarding the BoundsError, I believe you should only try to fill the gradient if it has nonzero length, see the example in the readme.

[felixjung]

Thanks for the reply, Miles. I was just about to close this issue, since I figured the gradient part out myself. I'll definitely check the MathProgBase solution!

[felixjung]

@mlubin Any docs for the standard MathProgBase solver options format?

[mlubin]

They're just keyword arguments to the solver object:

NLopt.jl/src/NLoptSolverInterface.jl

Line 20 in e7a4a28

function NLoptSolver(;algorithm::Symbol=:none, stopval::Real=NaN,

. The names of the parameters are solver dependent, so you could name this local_optimizer.

[felixjung]

Cool. Might take a look soonish.

[stevengj]

Yes, as you apparently figured out, just because you use a gradient-based algorithm does not mean that NLopt evaluates using a gradient on every function evaluation; it should use gradients on most of the function evaluations, but occasionally it will just request the function value (by passing a zero-length gradient).

Closing since the question of a MathProgBase keyword seems like a separate issue.