Roadmap 2024-25

[ocots]

Point 22/01/2024 (Joseph & Olivier)

Suivi de chemin

$h(x, \lambda) = 0$

• continuation (Dieci)
• simplicial

Méthodes directes

• RK général
• Différents algos d'optimisation

Méthodes indirectes

• F(x) = 0 : tester codes existants

Tir direct

• à développer

[jbcaillau]

Point 18/12/2023

@ocots @PierreMartinon @joseph-gergaud

0. Sujets stage M2.
1. forces vives / dispos. Se caler un point mensuel
2. interfaces vers autres modélisations ?
3. traits en Julia : voir cette discussion
4. load time! importer plus finement (diffeq, opti, plot...) : installation et utilisation
5. use cases / applications
6. pub (liste julia nationale, café julia...) / Journée Julia et Optimisation à Toulouse ?
7. juliacon'2024
8. FGS'2024

• opti : point solvers avec Alexis / Tangi / François
• opti : améliorer perf. en revoyant discrétisation vers direct
• AD (cf. postdoc + ingé PEPR)
• doc : abstraite (mettre grammaire), etc.
• indirect.jl ? abstract flows?
• point sur functional desc. (check PR baptiste)
• point bocop
• publier repo sur registry julia ?
• faire ménage sur issues / repos

[jbcaillau]

Point 28/02/2024

@ocots @PierreMartinon @joseph-gergaud

• @PierreMartinon @jbcaillau précompilation (voir ici)
• @PierreMartinon @jbcaillau issue install OptimalControl avec 1.10.x
• @PierreMartinon @joseph-gergaud performance discrétisation direct ; profiling (voir ce récap) : CTBase... (outils -> demander @alexis) ? benchmarking
• @ocots @jbcaillau refactoring (extraire solve de CTDirect, etc.)
• @ocots @jbcaillau point hamiltonian flow; use case (intérêt forme abstraite ?)
• @PierreMartinon @joseph-gergaud ajout schéma direct : peu prioritaire (cf. retex BOCOP) ; Euler explicite (cf. ResNets) ?
• planning, dispos (passage Toulouse JB)
• @joseph-gergaud @ocots homotopie
• stages : projet long SN3 -> mi-mars (interface web ct avec def + solve (direct) + plot), Y. Katif 06-09/2024 (M1, interface plus réactive), L. Astruc 05-08/2024 (M1, voir ici)
• galerie de problèmes (CTProblems, tutos + lien avec repos contenant des use cases), benchmarking (lien avec stage cité plus haut)
• financements suite (stages M1-M2)
• confs : @joseph-gergaud @ocots SMAI-MODE, FGS, JuliaCon, Julia optim day(s) Toulouse (toussaint 2024)
• prochain point (mensuel) : 20/3 11:00

[jbcaillau]

Point 20/03/2024

@ocots @PierreMartinon @joseph-gergaud

• typage / performance (revoir Julia tips) ; contrainte de polymorphisme (= pas juste Float64) pour AD (voir par ex. ForwardDiff)
• autre point : union utilisée pour scalaire ou vectoriel pour state, control, variable
• append et al dans CTBase et CTDirect vs. allocation statique (les tailles étant connues) : revoir fonctionnement algèbre linéaire de base pour se caler dessus (et attendre du user qu'il fasse de même)
• stagiaire : trouver un ou deux M1 (opti, use case MRI, géométrie...)
• use case matriciel : quantique, pb sur groupes de Lie (extdet)...
• transcription ocp vers ADNLPModel, cf. CTDirect ; ajouter la conversion explicitement dans l'API (WIP PR à suivre)
• prochain point : 25/4 14:00 (zoom)

[ocots]

Point du 25/04/2024

@PierreMartinon @joseph-gergaud @jbcaillau

Package CTDirect

• la création de l'init doit pouvoir être interne à la fonction solve : voir test_init de OptimalControl.jl.
• je préfère OCPInit à OptimalControlInit
• peut-être mieux

OCPInit(state=..., control=..., variable=...)

plutôt que x_init.

• mettre la valeur de l'objectif et la variable de coût $x^0(t)$ dans un champ de la solution.

Question : les fonctions solve et OCPInit à terme seront dans CTBase ? Cela changera le tutoriel dans CTDirect sur Goddard.

[ocots]

(suite)

• Scope des variables : https://gensoft.pasteur.fr/docs/julia/1.4.1/manual/variables-and-scoping.html
• Réfléchir à l'architecture du code : est-ce que l'init se trouve dans CTBase ?
• Etre capable de fournir un modèle NLP standard pour faire appels à des solveurs externes. Renvoyer un modèle ADNLP, JuMP...
• Améliorer le plot : plot d'une liste de solutions, donner une fonction de x, p... Pouvoir afficher ou non les adjoints. Mieux gérer les labels.
• Pour la définition abstraite du problème, il faut pouvoir tout définir sans caractère bizarre (par ex. autoriser <=, in, etc.)
• Pour récupérer les labels, on doit pouvoir écrire dans la définition de l'ocp : (q, v) ∈ R² ou x = (q, v) ∈ R².
• Intérêt des primitives fonctionnelles comme remove_constraint dans la mesure où ça coûte rien de rédefinir autant de nouveaux problèmes qu'on veut.

Future réunion : 25 mai 2024 15:00.

[jbcaillau]

@ocots merci pour le CR ; le 25 mai c'est un samedi, c'est quoi la bonne date 😬 ?

[ocots]

C'est mercredi 22 mai la bonne date :-)

[jbcaillau]

https://inria.webex.com/meet/jean-baptiste.caillau

[jbcaillau]

Point du 22/05/2024

• break avec ADNLPModels / SymbolicUtils
• stages (Toulouse en optimisation, Nice en quantique)
• aliases lors des déclarations de state et control (WIP merge)
• init
• JuliaCon 2024
• JuliaOpt (ENSEEIHT, 28-30 octobre 2024), budget IRIT + ANITI + PDE-AI (cf. version 2023)
• JuMP
• Dynamics type
• Go to general register
• prochain point mardi 25/06 14:00 (https://inria.webex.com/meet/jean-baptiste.caillau)

[jbcaillau]

Point du 25/06/2024

@ocots @PierreMartinon @joseph-gergaud

• modifs CTDirect.jl (NB : solve from CommonSolve.jl) : cible = réduire load grace aux pack. extensions
• JuliaCon : cible = OptimalControl v1.0, discussion ici
• demande IRIT plateforme logiciel (moyens)
• maj doc (tutos...)
• autres schémas (aux_fonctions), cf. aussi comparaison approche bvp ; Euler lien avec ML
• non uniform grids
• push -> allocate
• bvp
• perf / profiling
• DiffInterface pb. avec CTProblems
• point stage bench
• GUI Julia
• prochain point : 3/7 15:00 webex

[ocots]

[jbcaillau]

Point du 17/07/2024

@ocots @PierreMartinon @joseph-gergaud

• voir cette discussion
• enjeux sur control-toolbox: simplicité et performance
• simplicité = public cible ne va pas coder un schéma RK
• performance = comparaison raisonnable avec harcoded (hand coded) schemes (et JuMP ou équivalent)
• bilan premiers tests Yassine : ma57 mieux
• knitro : MKL + ma57 en interne ; a priori meilleur car région de confiance (expérimental)
• 2 pistes : (i) à la mano, (ii) utiliser outil de modélisation (type Examodels.jl)
• vérifier type instability : check @code warn_type ; voir Guillaume D. (ProfileView, JET, dispatch doctor...)
• tester NLPModels.jl : passer la structure creuse du jacobien des contraintes
• possibilité d'utiliser Examodels.jl sur code (vérifier surcharge sur fonctions simples, à la function tracing de JuMP)
• block banded matrices
• in place vs. out place (revoir nlp_constraint et calcul des contraintes)
• mieux utiliser ForwardDiff.jl (voir doc)
• tester directives @thread, @simd...
• benchmark contrôle / opti (cf. bench existant) : faire les deux
• passer sur GPU (type tableaux ad hoc)

[ocots]

[jbcaillau]

Point du 8/11/2024

@ocots @PierreMartinon @joseph-gergaud

• programme recherche pour ingénieur (demandes CNRS, SATT, groupe Calcul, ingé IRIT...)
• deadline pour demande CNRS : 25/11 -> faire un doc partagé
• vers la release 1.0 (cible : semaine du 9/12)
• performance : allocations, type instabilities, concrete types is_concrete_type / CheckConcreteStructs.jl), broadcast / fusing etc. (cf. perf. tips)
• use case minimal ADNLP (Goddard)
• restructuration (notamment CTBase -> CTParser, CTModels...) (cf. graphe ci-dessus)
• profiling (cf. retour Guillaume D.)
• v1.11 : CI ?
• contact CNES, ESA (Joseph)
• AD / solveur ODE : extraction ocp -> flot en passant contrôle maximisant) (fait bien le lien avec l'indirect) et revoir AD (performance ?)
• autre : approche BVP sur pénalisation intérieure contraintes et $\nabla_u H = 0$ implicite (Paul M.)
• prochain point : lundi 18/11 17:15

[ocots]

https://github.com/gdalle/CheckConcreteStructs.jl

[jbcaillau]

Point du 20/12/2024

@ocots @PierreMartinon @joseph-gergaud

Point CTDirect, notamment méthodes RK

• baisser tolérances (et repasser tests / tutos / applications...)
• réactiver runners Inria sur CTDirect

Restructuration CTModels (stable types...)

• Mayer et Lagrange : scalaires out_of_place
• signatures toujours vectoriel (pas scalaire), non-autonomes, avec variable (== [ ] si pas de variable)

Misc

• ODE / AD : tests @joseph-gergaud, voir aussi SimpleDiffEq.jl
• to come: OptimalControl.jl release 1.0 🤞🏾

[jbcaillau]

Point du 17/01/2025

backend AD pour direct (dont Enzyme.jl)

• type instability détecté par Enzyme.jl (vs. défaut actuel :optimize i.e. forward over reverse)
• 0 -> zero(x) / one(x) (cf. [Bug] Goddard 3D does not compile OptimalControl.jl#369 (comment), merci @abavoil 👍🏽)

CTModels / refonte code (type instabilities, etc.)

• @code_warntype sur CTModels.boundary_cons_nl! : comprendre (faire issue)
• NB : sur ce point, typer si nécessaire l'appel aux fonctions pour forcer le type de retour (x = f(y) :: T)
• idem pour path constraints
• faire la même vérif. avec JET (@report_opt)
• NB : from the doc

When no supertype is given, the default supertype is Any – a predefined abstract type that all objects are instances of and all types are subtypes of. In type theory, Any is commonly called "top" because it is at the apex of the type graph. Julia also has a predefined abstract "bottom" type, at the nadir of the type graph, which is written as Union{}. It is the exact opposite of Any: no object is an instance of Union{} and all types are supertypes of Union{}.

Comparaison JuMP, ADNLPModels

• sur test bio, perf. comparables JuMP / CTDirect, encore alloc 10x
• précompilation ?

Misc

• runners
• maj artifact
• récap sur issues
• CNRS : revoir avec Joseph
• planning semestre

Prochain point 24/1 16:00

[jbcaillau]

@ocots @PierreMartinon @joseph-gergaud typer les fermetures (closures), cf.

@code_warntype sur CTModels.boundary_cons_nl! : comprendre (faire issue)
NB : sur ce point, typer si nécessaire l'appel aux fonctions pour forcer le type de retour (x = f(y) :: T)

julia> f(x, y) = x + y
f (generic function with 2 methods)

julia> g(x) = f(x, y)
g (generic function with 1 method)

julia> @code_warntype g(2)
MethodInstance for g(::Int64)
  from g(x) @ Main REPL[21]:1
Arguments
  #self#::Core.Const(Main.g)
  x::Int64
Body::Any
1 ─ %1 = Main.f(x, Main.y)::Any
└──      return %1


julia> @report_opt g(2)
═════ 1 possible error found ═════
┌ g(x::Int64) @ Main ./REPL[21]:1
│ runtime dispatch detected: f(x::Int64, %1::Any)::Any
└────────────────────


julia> g(x) = f(x, y :: Float64)
g (generic function with 1 method)

julia> @code_warntype g(2)
MethodInstance for g(::Int64)
  from g(x) @ Main REPL[24]:1
Arguments
  #self#::Core.Const(Main.g)
  x::Int64
Body::Float64
1 ─ %1 = Main.f::Core.Const(Main.f)
│   %2 = Core.typeassert(Main.y, Main.Float64)::Float64
│   %3 = (%1)(x, %2)::Float64
└──      return %3


julia> @report_opt g(2)
No errors detected

[ocots]

No problem anymore: img

[jbcaillau]

Point du 24/01/2024

@ocots @PierreMartinon @joseph-gergaud

• CNRS : Joseph voit avec labo ce qui a été remonté
• CTModels + CTDirect
• test avec Enzyme.jl : en cours
• comparaison JuMP / ADNLPModels (cf. ici)
• prochain point : vendredi 31/1 16:30 (a priori sans moi, prévoir un autre lien visio)