Structure of OptimalControl.jl package

[ocots]

For the moment, the user can do the following:

using OptimalControl

@def ocp begin
    t ∈ [ 0, 1 ], time
    x ∈ R², state
    u ∈ R, control
    x(0) == [ -1, 0 ]
    x(1) == [ 0, 0 ]
    ẋ(t) == [ x₂(t), u(t) ]
    ∫( 0.5u(t)^2 ) → min
end

sol = solve(ocp)
plot(sol)

With the future release, since the plot function will be in an extension, then the user will have to do the following:

using OptimalControl
using Plots

@def ocp begin
# ...
end

sol = solve(ocp)
plot(sol)

[ocots]

We should think about what are the extensions and what is given. We could imagine that under OptimalControl.jl we always provide the definition function of an OCP and a transcription into a DOCP:

using OptimalControl

@def ocp begin
# ...
end

docp = DirectTranscription(ocp)

then, the user can solve docp with classical tools, getting first the NLP associated problem: nlp = NLP(docp).

[ocots]

Imagine we split CTBase.jl in CTBase.jl and CTPlots.jl containing the tools to plot. We also split CTDirect.jl into CTDirect.jl and CTSolve.jl. In the previous situation, it is like only CTBase.jl and CTDirect.jl are provided.

Now we can see CTPlots.jl and CTSolve.jl as extensions. First, the user could do:

using OptimalControl
using Plots
using StandardNLPSolver # this means that the user uses its own NLP solver 

@def ocp begin
# ...
end

docp = DirectTranscription(ocp)

sol = StandardNLPSolver.solve(NLP(docp))

plot(sol, ocp) # this is provided by CTPlots.jl which is loaded since we have: using Plots

[PierreMartinon]

But then CTSolve would contain all the solve aspects, including indirect methods, direct shootings etc ?

[ocots]

Actually, I don't have an idea for CTSolve.jl. Maybe it won't exist anymore.

[PierreMartinon]

For the moment, the user can do the following:

using OptimalControl

@def ocp begin
    t ∈ [ 0, 1 ], time
    x ∈ R², state
    u ∈ R, control
    x(0) == [ -1, 0 ]
    x(1) == [ 0, 0 ]
    ẋ(t) == [ x₂(t), u(t) ]
    ∫( 0.5u(t)^2 ) → min
end

sol = solve(ocp)
plot(sol)

With the future release, since the plot function will be in an extension, then the user will have to do the following:

using OptimalControl
using Plots

@def ocp begin
# ...
end

sol = solve(ocp)
plot(sol)

Fine with me. In the future we may even use another package than Plots, eg Makie.

[ocots]

Yes.

We have also to choose between:

plot(sol)

and

plot(sol, ocp)

to prevent changing to often the API.

[ocots]

We could see also CTSolve.jl as an extension and do:

using OptimalControl
using Plots
using ...

@def ocp begin
# ...
end

sol = solve(ocp)

plot(sol, ocp) # this is provided by CTPlots.jl which is loaded since we have: using Plots

but we need to figure out how CTSolve.jl is triggered. For the moment, we use NLPModelsIpopt.jl to solve the problem. If we do not want to load ipopt I don't know what to do here.

[jbcaillau]

@ocots @PierreMartinon @joseph-gergaud (pinging everyone, I actually missed this discussion!)

All fine. For the record:

• this is to alleviate (= minimise loading time) for OptimaControl.jl
• looks like it is a general design pattern not to import everything (solvers, even default ones) into a package
• AFAIR, CTDirect.jl is used to generate an NLP model, for instance an ADNLPModel (there, this package, as well as other packages defined other models - such as JuMP, ExaModels... - should be dependencies of CTDirect.jl)
• then we solve the generated docp using the appropriate solver, e.g. using NLPModelsIpopt.jl
• then we plot the solution; as pointed by @ocots above, one way to deal with the fact that the solution returned by the optimisation solver is not rich enough to be plotted, passing both the ocp and the sol
• don't see any need of CTSolve.jl or like
• all in all, the complete chain of actions might look like:

using OptimalControl
using NLPModelsIpopt
using Plots

@def ocp ...
docp = ADLNPModel(ocp) # or DirectTranscription(ocp; model=:adnlp)...
sol = Ipopt(docp)
plot(sol, ocp)

[PierreMartinon]

For what it's worth, I don't like having to pass the ocp in addition to the solution for a plot.
More generally I would like the solution to contain as much information as possible.
In CTDirect the docp includes a copy of the ocp exactly for this: to be self-sufficient.

Similarly, I think we really need to keep the solve method, as I suspect many users will prefer to have a ready-to-go package in OptimalControl, meaning you can do def ocp..., sol=solve(ocp) and plot(sol).
Keep in mind that all the initial guess options, including warm start and continuations, come through solve.
What people liked in bocop was the all-in-one aspect.

I still support the idea of enabling interactions with other packages, such as exporting the NPL problem / model.
Just don't stop here, and keep a core set of high-level functionalities from problem definition to solution analysis.

[jbcaillau]

OK. @PierreMartinon I am writing a follow-up of this in an issue. Core motivation right now = pulling solver(s) out of CTDirect.jl and trigger the possibility to solve by using NLPModelsIpopt thanks to the package extension mechanism.

NB. Same for plotting an ocp solution, thanks to an extension of CTBase.jl (thus pulling Plots.jl outside) and to a well-designed solution (also making sense for CTProblems.jl analytical solutions).

[jbcaillau]

control-toolbox/CTDirect.jl#115 (comment)

[jbcaillau]

@PierreMartinon @ocots guys, think we can close this discussion: up to you

[PierreMartinon]

ok for me