[Dev] Exa and problems

[ocots]

@jbcaillau is writing problems working with Exa. If the user makes:

beam(OptimalControlBackend(), :exa)

I need to throw an error telling to use beam_s with Exa.

[ocots]

@jbcaillau Do we set as the default:

beam_s(OptimalControlBackend()) # -> beam_s(OptimalControlBackend(), :exa)

[jbcaillau]

@jbcaillau Do we set as the default:

beam_s(OptimalControlBackend()) # -> beam_s(OptimalControlBackend(), :exa)

why not. will it be clear for the user if the default backend is different depending on the problem?

[ocots]

Actually I think it is not a good idea. As you say it wouldn't be clear.

[amontoison]

@jbcaillau @ocots

julia> nlp = beam(OptimalControlBackend(), :exa)
┌ Warning: currently replacing Ipopt with MadNLP for :exa
└ @ CTDirect /tmp/packages/CTDirect/JKtRC/src/solve.jl:83
ERROR: ParsingError: 
Line 6: ẋ(t) == [x₂(t), u(t)]
dynamics must be defined coordinatewise
Stacktrace:
 [1] macro expansion
   @ /tmp/packages/OptimalControlProblems/oWIpE/ext/OptimalControlModels/beam.jl:47 [inlined]
 [2] (::OptimalControlModels.var"#4#22"{…})(; scheme::Symbol, grid_size::Int64, backend::Nothing, init::Tuple{…}, base_type::Type)
   @ OptimalControlModels /disk/amontoison/CTParser.jl/src/onepass.jl:1157
 [3] build_nlp!(docp::CTDirect.DOCP{…}, nlp_model::CTDirect.ExaBackend, x0::Vector{…}; grid_size::Int64, disc_method::Symbol, exa_backend::Nothing, kwargs::@Kwargs{…})
   @ CTDirectExtExa /tmp/packages/CTDirect/JKtRC/ext/CTDirectExtExa.jl:53
 [4] direct_transcription(ocp::Model{…}, description::Symbol; grid_size::Int64, disc_method::Symbol, time_grid::Nothing, init::@NamedTuple{…}, lagrange_to_mayer::Bool, kwargs::@Kwargs{})
   @ CTDirect /tmp/packages/CTDirect/JKtRC/src/solve.jl:266
 [5] beam(::OptimalControlBackend, description::Symbol; N::Int64, kwargs::@Kwargs{})
   @ OptimalControlModels /tmp/packages/OptimalControlProblems/oWIpE/ext/OptimalControlModels/beam.jl:57
 [6] beam(::OptimalControlBackend, description::Symbol)
   @ OptimalControlModels /tmp/packages/OptimalControlProblems/oWIpE/ext/OptimalControlModels/beam.jl:30
 [7] top-level scope
   @ REPL[27]:1
Some type information was truncated. Use `show(err)` to see complete types.

[amontoison]

I wanted to solve the problems on GPU with madnlp and madncl.
Is it possible or not yet?

[ocots]

For the moment to get a problem written component-wize and compatible with ExaModels, you need to add the suffix _s to the name:

docp = beam_s(OptimalControlBackend(), :exa)
nlp = nlp_model(docp)

Note

The problem with _s are compatible with ExaModels and ADNLPModels. We will merge this in the future I think.

If what I gave do not work, try:

docp = beam_s(OptimalControlBackend(), :exa, :madnlp)
nlp = nlp_model(docp)

Note

The solver is useless but I don't know if we have removed it yet.

[ocots]

@amontoison See https://github.com/control-toolbox/CTBenchmarks.jl/blob/2b1d60d2fc6548ecd42adf253965272528a96cbe/src/utils.jl#L218-L287

[amontoison]

Thanks @ocots!
But I still don't know how to get a model on GPU.
I obtain a CPU ExaModel with what you shared.

[amontoison]

🤔

julia> docp = beam_s(OptimalControlBackend(), :exa_gpu)
ERROR: AmbiguousDescription: the description (:exa_gpu,) is ambiguous / incorrect
Stacktrace:
 [1] complete(list::Symbol; descriptions::NTuple{6, Tuple{Symbol, Symbol}})
   @ CTBase /tmp/packages/CTBase/eOENb/src/description.jl:140
 [2] complete
   @ /tmp/packages/CTBase/eOENb/src/description.jl:132 [inlined]
 [3] #complete#3
   @ /tmp/packages/CTBase/eOENb/src/description.jl:149 [inlined]
 [4] complete
   @ /tmp/packages/CTBase/eOENb/src/description.jl:146 [inlined]
 [5] parse_description(description::Tuple{Symbol}, info::Symbol)
   @ CTDirect /tmp/packages/CTDirect/DgVuH/src/solve.jl:122
 [6] direct_transcription(ocp::Model{…}, description::Symbol; grid_size::Int64, disc_method::Symbol, time_grid::Nothing, init::@NamedTuple{…}, lagrange_to_mayer::Bool, kwargs::@Kwargs{})
   @ CTDirect /tmp/packages/CTDirect/DgVuH/src/solve.jl:357
 [7] beam_s(::OptimalControlBackend, ::Symbol, ::Vararg{Symbol}; grid_size::Int64, parameters::Nothing, kwargs::@Kwargs{})
   @ OptimalControlModels /tmp/packages/OptimalControlProblems/58jXr/ext/OptimalControlModels_s/beam_s.jl:69
 [8] beam_s(::OptimalControlBackend, ::Symbol, ::Vararg{Symbol})
   @ OptimalControlModels /tmp/packages/OptimalControlProblems/58jXr/ext/OptimalControlModels_s/beam_s.jl:30
 [9] top-level scope
   @ REPL[26]:1
Some type information was truncated. Use `show(err)` to see complete types.

[ocots]

Sorry. See this:

https://github.com/control-toolbox/CTBenchmarks.jl/blob/2b1d60d2fc6548ecd42adf253965272528a96cbe/src/utils.jl#L148-L155

[ocots]

@jbcaillau Is it sufficient to set backend=CUDABackend() in your build_exa to make a GPU solve with madnlp? Is it automatic if we make both using MadNLPGPU and using MadNLPMumps. I found not very clear how the solvers and modellers are chosen.

[amontoison]

Note that we officially support CUDABackend() and ROCBackend() in MadNLPGPU. So I am scared of an automatic setup of the backend.
On my side, I prefer is it is CPU() by default and we specify a different one by our own for GPU.

[jbcaillau]

FTR the following pb should be added to the _s versions:

• bioreactor: may be not, cf. non smooth (max...) inside
• cart pendulum
• moonlander

NB : https://claude.ai/share/8f821909-1419-439f-b03d-a0c0b024dc43