[Bug] MadNLP with ADNLPModels is not working

[ocots]

@AnasXbouali says that

solve(ocp, :direct, :adnlp, :madnlp)

does not work anymore, but

solve(ocp, :direct, :adnlp, :ipopt)

does.

@jbcaillau @PierreMartinon Any idea?

[AnasXbouali]

Here is the precise issue I encounter (that does not occur when using :ipopt)

[jbcaillau]

@AnasXbouali try to solve using solve(ocp, :adnlp, :madnlp), or even just solve(ocp, :madnlp) as :adnlp is the default.

i suspect that it is just an issue with options (:direct) passed to MadNLP (while they should not)

@PierreMartinon ?

[AnasXbouali]

@jbcaillau Thanks for the suggestion; indeed,

solve(ocp, :adnlp, :madnlp) 

does work !

For other details I had to add "nlp_options"

So, now to use MadNLP ; it's :

sol = solve(ocp, :adnlp, :madnlp;
            disc_method=:gauss_legendre_3, grid_size=N, init=sol,
            nlp_options=(; tol=1e-8, max_iter=2000, print_level=0))

[ocots]

I am not sure it is the expected behavior nonetheless. And it is not what the documentation says I guess.

[PierreMartinon]

Hi everyone @AnasXbouali @jbcaillau @ocots

The culprit is actually the print_level option: MadNLP expects a specific type MadNLP.LogLevels, and sadly does not accept an integer like Ipopt. Valid values are: MadNLP.{TRACE, DEBUG, INFO, NOTICE, WARN, ERROR}. We picked INFO as default.

Passing an integer fails

julia> sol=solve(beam().ocp, :madnlp, print_level=4);
▫ This is OptimalControl version v1.1.1 running with: direct, adnlp, madnlp.

▫ The optimal control problem is solved with CTDirect version v0.16.4.

   ┌─ The NLP is modelled with ADNLPModels and solved with MadNLP.
   │
   ├─ Number of time steps⋅: 250
   └─ Discretisation scheme: trapeze

ERROR: MethodError: no method matching parse_option(::Type{MadNLP.LogLevels}, ::Int64)

Passing the appropriate type works

julia> sol=solve(beam().ocp, :madnlp, print_level=MadNLP.INFO);
▫ This is OptimalControl version v1.1.1 running with: direct, adnlp, madnlp.

▫ The optimal control problem is solved with CTDirect version v0.16.4.

   ┌─ The NLP is modelled with ADNLPModels and solved with MadNLP.
   │
   ├─ Number of time steps⋅: 250
   └─ Discretisation scheme: trapeze

This is MadNLP version v0.8.7, running with umfpack

Edit @AnasXbouali I suspect your nlp_options tuple is ignored, which would indeed remove the error with the print_level :D Can you retry with max_iter=0 and check the iterations ? @ocots Maybe a missing splat for nlp_options ?

[AnasXbouali]

@PierreMartinon Thanks! I just checked that "nlp_options" is ignored (when changing max_iter to 0, or tolerance to 1e-10, it was not taken into account). And, when adapting the print_level it works 👍

[PierreMartinon]

By the way, we could ask the MadNLP team about accepting integers as well, it looks like their type could be something similar to a C ENUM.
Which reminds me about the objective sign for maximization problems: they minimize the opposite and return the transformed objective in the NLP solution (unlike Ipopt).

[ocots]

@AnasXbouali It is normal that the options you pass to the solve method depends on the solver you choose. We do not uniform the names, since it would be confusing for someone who have habits with the solvers. However, we could imagine to map madnlp options to ipopt names, but there are some options in ipopt that do not even exist for madnlp.

We explain in the documentation that the options depends on the solver, see https://control-toolbox.org/OptimalControl.jl/stable/manual-solve.html#manual-solve-solvers-specific-options.

• MADNLP options: https://madsuite.org/MadNLP.jl/stable/options
• IPOPT options: https://coin-or.github.io/Ipopt/OPTIONS.html.

Note

I need to add an example of an options with the same name but different values to provide.

[ocots]

The documentation will be clearer: #631.

[ocots]

By the way, we could ask the MadNLP team about accepting integers as well, it looks like their type could be something similar to a C ENUM. Which reminds me about the objective sign for maximization problems: they minimize the opposite and return the transformed objective in the NLP solution (unlike Ipopt).

@frapac What do you think?

[jbcaillau]

By the way, we could ask the MadNLP team about accepting integers as well, it looks like their type could be something similar to a C ENUM.
Which reminds me about the objective sign for maximization problems: they minimize the opposite and return the transformed objective in the NLP solution (unlike Ipopt).

@PierreMartinon please issue our MadNLP colleagues 🙂