Organisation des packages de l'éco-système control-toolbox

[control-toolbox]

Organisation des packages de l'éco-système control-toolbox

But : des outils et exemples pour la résolution de problèmes de contrôle optimal.

Voici les noms des packages pour le moment avec la description ci-dessous. Naming guidelines

• Descriptions ou CTDescriptions ou ...
• Flows ou CTFlows ou ...
• Optimisation ou CTOptimisation ou NLPSolvers ou ...
• ControlToolbox ou OptimalControl ou ControlSolvers ou ...
• Paths ou CTPaths ou PathSolvers ou ...
• NLESolvers ou NLEquations ou ...

L'organisation pour le moment :

Package Descriptions pour les solveurs

In the future control toolbox, there will be solvers for optimal control problems but also methods to compute flows of ode (based on DifferentialEquations package), interfaces to NLP solvers (as JuMP), interfaces to NLE solvers (as MINPACK or NLSolve) but also a personal differential path following method to solve a one-parameter family of NLE equations.

The solvers will be called via a solve method as in the CommonSolve package but with an additional "description" of the method that will be called by the solver. For instance, if you want to solve an optimal control problem via a descent method with backtracking, with an optional argument grid set to my_grid, you will do

sol = solve(ocp, :descent, :backtracking, grid=my_grid)
# or
sol = solve(ocp, (:descent, :backtracking), grid=my_grid)
# or
sol = solve(ocp, :backtracking, grid=my_grid) # backtracking is only valid for descent method

Package Flows

• Pour calculer le flot de champs de vecteurs, champs de vecteur hamiltoniens (obtenus ou non à partir d'un hamiltonien).
• Le nom n'est pas valide pour l'enregistrement officiel. Il faut donc en trouver un autre.

Package Optimisation

• Le nom est à trouver.
• L'idée de ce package est de regrouper les solveurs de problèmes d'optimisation avec ou sans contraintes.
• J'ai pour l'instant écrit un solveur de descente et je compte ajouter une région de confiance juste pour commencer à structurer le package.
• Il y aura ensuite par exemple des interfaces au package JuMP.
• L'idée est d'avoir une méthode solve du genre

  sol = solve(nlp, description; kwargs) # kwargs for options

• On aurait une méthode de construction d'un problème NLP comme pour la construction d'un problème OCP :

  nlp = NLP(f)

  par exemple si on veut résoudre le problème $\min f(x)$, $x \in \mathbb{R}^n$.

Important. On passe par une méthode de construction pour cacher le type qui est géré par la méthode NLP. Le type va dépendre des arguments en entrée. Ensuite, en fonction du type, on peut ou pas appeler certaines méthodes. De plus, les options valides dépendent de la méthode choisie.

Package ControlToolbox

• Si on considère que control-toolbox correspond à tout l'éco-système avec les packages et les dépôts d'exemples, alors peut-être que l'on pourrait choisir autre chose comme nom pour remplacer ControlToolbox. Par exemple OptimalControl, OptimalControlSolvers...
• Ce package permet de :
  • construire un problème de contrôle optimal via une méthode OCP par exemple. Il est important que le type soit caché pour l'utilisateur qui veut juste construire un problème puis jouer avec.
  • résoudre le problème via un solveur à choisir par le "concept" de Description.
  • analyser la solution : accès à la solution, affichage...

Autres packages et remarques

• Paths ou Path ou autre. Pour le calcul de chemins via homotopie différentielle.
• NLESolvers ou NLEquations pour la résolution de systèmes d'équations non linéaires.

Remarques.

• A voir si on n'aurait pas un solveur de PMP.

[control-toolbox]

Penser à ajouter du contenu ici : https://control-toolbox.github.io. Quel contenu ?

[control-toolbox]

Les noms possibles :

• OptimalControl
• SolverDescription
• OptimisationSolvers
• PathFollowingSolvers
• EquationSolvers
• DifferentialFlows or ContinuousFlows

[control-toolbox]

Est-ce que l'on fait un package pour les exceptions et un package pour les callbacks ?

[control-toolbox]

On pourrait faire un package CTTools qui contient Descriptions, Callbacks et Exceptions.

[control-toolbox]

L'éco-système control-toolbox contiendrait donc comme packages :

OptimalControl : le package principal permettant de faire la résolution de problèmes de contrôle optimal par des méthodes directes et indirectes avec "l'analyse" et l'affichage des solutions.

ToolsCT ou CTTools : contient les fonctions liées à la notion de description d'algorithmes, les callbacks et les exceptions utiles pour tout l'éco-système control-toolbox.

FiniteOptimisationSolvers ou FiniteOptimisation ou NLPSolvers : contient des solveurs de problèmes d'optimisation en dimension finie avec ou sans contraintes, et des interfaces à des solveurs existants comme JuMP.

PathFollowing : contient des méthodes de suivi de chemin différentiel.

DifferentialFlows or ContinuousFlows : contient des méthodes de calcul de flots en tout genre.

On aura aussi un package pour faire la résolution de NLE, de BVP, etc. Comment l'appeler ? Sachant, que l'on fera peut-être de la résolution de PMP ou de fonction de tir, mais là c'est du NLE.

NonLinearEquationsSolvers, PMPSolvers, ShootingSolvers...

[control-toolbox]

Je continue et j'en suis à :

• OptimalControl
• ControlToolboxTools
• OptimisationSolversInterfaces ou CommonSolveOptimisation
• EquationsSolversInterfaces ou CommonsSolveEquations
• PathFollowing
• HamiltonianFlows

[control-toolbox]

Voici un exemple de wrapper : https://github.com/SciML/SciMLNLSolve.jl

[control-toolbox]

Pour rééxporter le contenu d'un package, utiliser @reexport.

[control-toolbox]

Les packages CommonSolveOptimisation et CommonsSolveEquations n'ont pas vocation à être visible donc je propose de les renommer CTOptimization et CTNonLinearSolve qui seront de simples passerelles vers à terme les packages Optimization et NonLinearSolve.