Suivi stage I. Mimoun

[jbcaillau]

Point du 17/06/2024

@ibtissammim

• [x] tester control-toolbox sous Julia, notamment les tutos
• [x] s'approprier le problème de saturation de deux spins décrit Section 2.1 (voir (2)) et 4 de ce papier :

• [x] commencer à coder ce problème en Julia pour le résoudre par une approche directe, comme fait au 6.1 dans la référence citées, pour reproduire les résultats Figures 9 et 10

@

[jbcaillau]

See also: https://github.com/control-toolbox/CTDirect.jl/issues/119

[jbcaillau]

Point du 24/06/2024

@ibtissammim

• [x] vérifier attendus sur rapport 2ème année ENSEEIHT (option big data & HPC)
• poursuivre résolution du pb de la réf. ci-dessus
• infos sur projets Julia, voir ici
• [x] julia + vscode + git (under wsl) set

[ibtissammim]

Bonjour Monsieur, Est ce que les constantes du problème sont bien : ε = 0.1 Γ = 9.855e-2 γ = 3.65e-3 ? Cordialement, Ibtissam

[ibtissammim]

Bonjour Monsieur,

Le problème ne converge plus. En effet, j'ai constaté que j'avais mal défini les conditions initiales. Après avoir effectué les changements nécessaires, le problème ne converge plus et j'obtiens l'erreur suivante : EXIT: Converged to a point of local infeasibility. Problem may be infeasible. knot-vectors must be unique and sorted in increasing order

Je vais mettre la nouvelle version du code sur Git.

Cordialement, Ibtissam MIMOUN

[jbcaillau]

@ibtissammim Deux exemples avec "warm start" pour continuation sur condition initiale : https://control-toolbox.org/CTDirect.jl/stable/tutorial.html#Initial-guess-options https://control-toolbox.org/docs/optimalcontrol/dev/tutorial-batch.html

[ibtissammim]

D'accord, merci beaucoup.

[jbcaillau]

Point du 1er juillet 2024

@ibtissammim

• [x] mettre au propre dans un code commun les 3 continuations utilisées (sur condition initiale)
• [x] comparer (structure des trajectoires dans la sphère de Bloch) les différents minima locaux trouvés
• [x] utiliser aussi l'initialisation par le système à un seul spin
• [ ] réaliser un notebook markdown du type de celui-là (voir source ici)
• [ ] résolution par tir simple du pb de saturation / contraste, cf. https://github.com/control-toolbox/spin/issues/2 ; voir notamment Section 7.1 du papier pour calcul des contrôles singuliers

Misc

• install juliaup

[jbcaillau]

Point du 3 juillet 2024

@ibtissammim

• [ ] @jbcaillau passer à la CI avec Documenter.jl
• [ ] pb contraste : code direct
• [ ] pb contraste : code indirect (voir https://github.com/control-toolbox/spin/issues/1#issuecomment-2200387529)

[ibtissammim]

@jbcaillau J'ai un petit soucis avec la fonction de tir. En effet, je vois pas d'où vient le H01 et H1 dans la section 7.1.

[jbcaillau]

@jbcaillau J'ai un petit soucis avec la fonction de tir. En effet, je vois pas d'où vient le H01 et H1 dans la section 7.1.

$$ H_0(x,p) = \langle p,F0(x) \rangle,\quad H{01} = \lbrace H_0,H_1 \rbrace $$

(crochet de Poisson, voir ici)

[ibtissammim]

@jbcaillau C'est quoi les fonctions : pz1 et pz2 de la page 35? Merci

[jbcaillau]

@ibtissammim

Point du 8/7/2024

• terminer la doc
• pour le tir multiple, utiliser fsolve de MINPACK.jl, voir ici

[ibtissammim]

@jbcaillau Bonjour monsieur, J'ai réussi à faire marché la fonction de tir, avec MINPACK, mais la solution ne converge pas, comment changer le p0? est ce que je le fais aléatoirement? Merci

[jbcaillau]

bonjour @ibtissammim ; merci pour les nouvelles. pour le p0, surtout pas ! normalement, tu dois avoir une bonne initial guess avec le direct et sol.costate(0). si ça ne suffit pas à faire converger, re-résout le pb avec une grille plus fine.

[ibtissammim]

Bonjour @jbcaillau , shoot! me retourne une valeur, que signifie-t-elle ? Et est ce que la norme du vecteur s de shoot! doit être à une certaine valeur ? La methode indirecte converge mais en changeant la tolérance de fsolve qui est normalement $10^{-8}$ à $10^{-6}$

[jbcaillau]

Bonjour @jbcaillau , shoot! me retourne une valeur, que signifie-t-elle ? Et est ce que la norme du vecteur s de shoot! doit être à une certaine valeur ? La methode indirecte converge mais en changeant la tolérance de fsolve qui est normalement 10−8 à 10−6

@ibtissammim shoot! retourne la dernière valeur affectée, ici une composante du tir : https://github.com/control-toolbox/spin/blob/f7def56020859ad0f893971695bd5bf70fed9b55/src/tir_saturation.jl#L75

C'est plus propre d'ajouter à la fin un return nothing.

OK pour les tolérances, c'est normal (on reverra ensemble).

[ibtissammim]

Bonjour @jbcaillau, Lorsque j'essaye de déployer la page web de tir_saturation.md que je viens d'écrire exactement comme bisaturation.md, j'ai cette erreur : Alors que j'ai effectué des changements dans documentation.yml : Et aussi des modifications dans make.jl: Est que je dois changer un autre fichier ? Merci

[jbcaillau]

Bonjour @ibtissammim il ne faut pas faire comme ça dans Documentation.yml : fais ton .md sans te poser de question, je fais les modifs après pour rendre le déploiement possible.

[ibtissammim]

D'accord @jbcaillau, merci.

[ibtissammim]

Bonjour @jbcaillau @ocots,

J'ai un petit souci avec l'utilisation du solveur linéaire MA57 avec HSL. Les valeurs du contrôle sont l'opposé de ce que je dois trouver. Je ne vois pas d'où vient cette erreur. Merci!!

[ocots]

Ce n'est pas nécessairement une erreur car c'est symétrique. C'est tout de même légèrement surprenant que le solveur converge vers la solution symétrique.

[jbcaillau]

@ocots en effet, symétrie $(y, z, u) \mapsto (-y, z, -u)$

[jbcaillau]

@ibtissammim je viens de faire des modifs dans la doc (et dans les fichiers CI / doc), tout passe et c'est mergé dans la branche main https://github.com/control-toolbox/spin/pull/9

Par contre, la doc tir_saturation.md est à compléter (j'ai supprimé la fin qui ne passait pas, et semblait obsolète

NB. Il faut visiblement mettre des global pour les variables qui apparaissent dans les boucles (alors que ce n'est plus la peine en julia standard^1 / hors Documenter)

[ibtissammim]

D'accord @jbcaillau

[jbcaillau]

@ibtissammim pour la suite, voir :

• le code BVP sur cet exemple cet exemple (Van der Pol, et tester d'abord la version primale, a priori moins précise mais plus simple)
• le papier qui explique la méthode

[ibtissammim]

Bonjour @jbcaillau, A quoi correspond le paramètre mu? puisque je le vois pas définit dans la fonction init. Je suppose que cette fonction définit la dynamique, et donc puisque dans la dynamique du problème j'ai besoin de \epsilon, cette variable "z" doit le contenir. est ce que c'est correct? Voici ce comment j'ai définit la fonction ode :

[ibtissammim]

Bonjour @jbcaillau, je suis bloquée et je ne comprends pas comment notre problème de spin peut être traité de la même manière que les autres problèmes.

[jbcaillau]

bonjour @ibtissammim rdv 16:30 ce mercredi pour un point zoom : https://univ-cotedazur.zoom.us/my/caillau

Bonjour @jbcaillau, je suis bloquée et je ne comprends pas comment notre problème de spin peut être traité de la même manière que les autres problèmes.

[ibtissammim]

D'accord @jbcaillau, Merci :)

[jbcaillau]

@ibtissammim https://github.com/control-toolbox/BVP-DAE/issues/1#issuecomment-2262397840

[PlMlsn]

@ibtissammim @jbcaillau Si je peux me permettre, je pense que le plus simple est de partir du problème Goddard primal-dual. D'une part c'est un problème à temps minimal comme celui que vous traitez. Par ailleurs, en réalité, la méthode primale-duale est assez simple à implémenter car elle est très systématique.

[PlMlsn]

Bonjour @jbcaillau, A quoi correspond le paramètre mu? puisque je le vois pas définit dans la fonction init. Je suppose que cette fonction définit la dynamique, et donc puisque dans la dynamique du problème j'ai besoin de \epsilon, cette variable "z" doit le contenir. est ce que c'est correct? Voici ce comment j'ai définit la fonction ode :

En général, je note z la variable contenant les solutions des équations algébriques. Plus précisément, il s'agit du contrôle u et de tous les multiplicateurs des contraintes. Dans ce cas, la variable mu est le multiplicateur associé à la contrainte d'état.

[jbcaillau]

Bonjour @jbcaillau, A quoi correspond le paramètre mu? puisque je le vois pas définit dans la fonction init. Je suppose que cette fonction définit la dynamique, et donc puisque dans la dynamique du problème j'ai besoin de \epsilon, cette variable "z" doit le contenir. est ce que c'est correct? Voici ce comment j'ai définit la fonction ode :

En général, je note z la variable contenant les solutions des équations algébriques. Plus précisément, il s'agit du contrôle u et de tous les multiplicateurs des contraintes. Dans ce cas, la variable mu est le multiplicateur associé à la contrainte d'état.

🙏🏽 merci @PlMlsn en effet, on a vu ça hier : $\mu$ pour $g(x) \leq 0$, $\eta$ pour $c(x,u) \leq 0$, de mémoire

[jbcaillau]

@ibtissammim @jbcaillau Si je peux me permettre, je pense que le plus simple est de partir du problème Goddard primal-dual. D'une part c'est un problème à temps minimal comme celui que vous traitez. Par ailleurs, en réalité, la méthode primale-duale est assez simple à implémenter car elle est très systématique.

@PlMlsn dans l'immédiat, il s'agit de tester ton code python sur le cas de contrôle quantique (pas de réimplémenter). merci pour le conseil !

[ibtissammim]

Bonjour @jbcaillau, A quoi correspond le paramètre mu? puisque je le vois pas définit dans la fonction init. Je suppose que cette fonction définit la dynamique, et donc puisque dans la dynamique du problème j'ai besoin de \epsilon, cette variable "z" doit le contenir. est ce que c'est correct? Voici ce comment j'ai définit la fonction ode :

En général, je note z la variable contenant les solutions des équations algébriques. Plus précisément, il s'agit du contrôle u et de tous les multiplicateurs des contraintes. Dans ce cas, la variable mu est le multiplicateur associé à la contrainte d'état.

Merci beaucoup pour votre réponse @PlMlsn.