Rethink package purpose

[jbcaillau]

role of package vs. CTBase.jl has been shifting a bit. must rethink. as the root package of the ecosystem, should provide

• definition
• solve
• plot

for an ocp.

[ocots]

Actually it is not a tree but a graph with the constraints that there is no cycle in the ct-ecosystem and that CTBase.jl does not depend on any other ct-ecosystem package.

stateDiagram-v2
          CTBase --> CTProblems
          CTBase --> CTOptimization
          CTBase --> CTDirectShooting
          CTBase --> CTFlows
          CTBase --> CTDirect
          CTBase --> OptimalControl
          CTOptimization --> CTDirectShooting
          CTFlows --> CTDirectShooting
          CTFlows --> OptimalControl
          CTDirectShooting --> OptimalControl
          CTDirect --> OptimalControl

The package CTProblems.jl is used for unit test in the following packages.

stateDiagram-v2
          CTProblems --> CTDirectShooting
          CTProblems --> CTDirect
          CTProblems --> OptimalControl

[ocots]

I think it is important that OptimalControl exports only what we want the user to have. For the moment, we reexport everything, cf.

module OptimalControl

# using
using Reexport

# include modules
@reexport using CTBase
using CTDirect
using CTDirectShooting

# flows
@reexport using CTFlows

# Other declarations
const __display = CTBase.__display

# resources
include("solve.jl")

# export functions only for user
export solve

end

[ocots]

The package OptimalControl.jl selects the different methods we can use:

algorithmes = add(algorithmes, (:direct, :ADNLProblem, :ipopt))
algorithmes = add(algorithmes, (:direct, :shooting, :descent, :bfgs, :bissection))
algorithmes = add(algorithmes, (:direct, :shooting, :descent, :bfgs, :backtracking))
algorithmes = add(algorithmes, (:direct, :shooting, :descent, :bfgs, :fixedstep))
algorithmes = add(algorithmes, (:direct, :shooting, :descent, :gradient, :bissection))
algorithmes = add(algorithmes, (:direct, :shooting, :descent, :gradient, :backtracking))
algorithmes = add(algorithmes, (:direct, :shooting, :descent, :gradient, :fixedstep))

It could be interesting to create a mechanism to select from the user requirements a method which "insure" the resolution of the problem. In CTDirect.jl, we have a function which returns a boolean telling if the kind of ocp passed in argument is treated or not.

[jbcaillau]

Very nice graph [^1]! A bit puzzled by OptimalControl.jl being at the bottom of this not-a-tree graph. To be discussed.

[^1]: Julia generated 🙂?

[ocots]

It is just markdown.

[ocots]

We need also a mechanism for initialization. The user should provide different kind of init, then OptimalControl.jl transforms it to one type of init and then pass it to the solver.

[ocots]

But I agree that we must rethink the packaging. If we add the two mechanisms

• selection of a solver
• initialisation

where should they be?

[jbcaillau]

It is just markdown.

ohlalala 😍