Differences

This shows you the differences between two versions of the page.

--- commit:2018:01_06 [2018/01/06 22:11] – [LineSearch - Initial Balancing et IterationResolution] wautelet
+++ commit:2018:01_06 [2018/01/09 22:53] (current) – wautelet
@@ Line 3: / Line 3: @@
 Ce commit est pour un petit nettoyage de la routine IterationResolution.
-==== IterationResolution ====
+==== LineSearch - Initial Balancing et IterationResolution ====
-J'ai fait entré la ligne de code im.incrementIterationNo() dans le "if/else im.getMaxNbOfIterationsReached()", ce qui est beaucoup plus cohérent !
+Si on désire utiliser l'algorithme du line search, cette méthode ne doit pas être activée si nous avons que le résidu du line search est positif c'est à dire que la direction utilisée dans le line search est une direction ascendante (et non descendante). Dans ce cas de figure, nous devons utiliser la méthode classique de Newton Raphson $\alpha = 1$ selon la recommandation de M.A. Crisfield.
-J'ai commentarisé la ligne de commande  "this->metafor.getDomain().getEqualityDofConstraintsSet().impose();" car ceci est fait plus bas suite à la routine dofsCorrections().
+Le résidu du line search est une fonction de la taille du pas $\alpha$ le long de la direction de recherche $\mathbf{\Delta x}^{(i)}$ obtenue par la méthode de Newton-Raphson à l'itération $(i)$ :
-J'ai formalisé la sortie du Line Search comme les itérations mécaniques : notations scientifiques sous forme exponentielle.
+$$ res_{LS} \left(\alpha \right) = \mathbf{F}^{OOB}\left(\mathbf{x}^{(i)}+\alpha \mathbf{\Delta x}^{(i)} \right)  . \mathbf{\Delta x}^{(i)} $$
-==== LineSearch - Initial Balancing et IterationResolution ====
+Dans le cas échéant où $\alpha = 0$, nous avons que
-Si on désire utiliser l'algorithme du line search, cette méthode ne doit pas être activée si nous avons que le résidu du line search est positif c'est à dire que la direction utilisée dans le line search est une direction ascendante (et non descendante) :
+$$ res_{LS} \left(0 \right) = \mathbf{F}^{OOB}\left(\mathbf{x}^{(i)} \right)  . \mathbf{\Delta x}^{(i)} $$
-Le résidu du line search est une fonction de la taille du pas $\alpha$ le long de la direction de recherche $\Delta x$ :
+Puisque la direction de recherche $\mathbf{\Delta x}^{(i)}$ respecte la relation suivante :
-$$ res_{LS}^{(0)} \left(\alpha = 0 \right) = \mathbf{F}\left(\mathbf{x}+\alpha \mathbf{\Delta x} \right)  . \mathbf{\Delta x} $$
+$$\mathbf{K}_{T}^{(i)} . \mathbf{\Delta x}^{(i)} = - \mathbf{F}^{{OOB}^{(i)}}$$
-Dans le cas échéant où $\alpha = 0$, nous avons que
+Ainsi, nous avons que le résidu du line search est négatif en $\alpha = 0$ si la matrice de raideur tangente est définie positive :
+$$ res_{LS} \left(0 \right) = - \ \mathbf{\Delta x}^{(i)} . \mathbf{K}_{T}^{(i)} . \mathbf{\Delta x}^{(i)} $$
+<note important>Ceci permet de clarifier la remarque de Luc dans iterationResolution() :
+<code>
+            if (res_k > 0.0) // test Lpx (pas logique mais snecmaRupt + DSS pivot nul => res > 0 ...)
+            {
+                rester_ls = false;
+                WARNING_MESSAGE("LineSearch res_k > 0");
+            }
+</code>
+ </note>
+==== Nettoyage du flag forcesAreComputed de IterationManager ====
+Ce flag est utilisée principalement pour éviter de calculer deux fois d'affiler les forces lorsque que l'on utilise le Line Search. Par exemple, apps_qs_cont2AnaLineSearch, nous avons au dernier step :
+<code>
+ *** STEP 28: t= 2 - dt= 0.015238 - CPU= 1.72s/6.60s
-Dans ce cas de figure, nous devons utiliser la méthode classique de Newton Raphson $\alpha = 1$.
+mechanical iteration  0 : Rmean =   1.500380e-01 Rmax =   8.334497e+01 (Calcul des forces en $\mathbf{x}^(0)$)
+cpuRatio = 4 reactualisation = 1 iterationIsRefused = 0
+  - Line search : iteration  0, coefficient =   0.000000e+00, residual =  -8.948260e-02
+  - Line search : iteration  1, coefficient =   1.000000e+00, residual =   7.992926e-04 (Calcul des forces en$\mathbf{x}^(1)$)
+mechanical iteration  1 : Rmean =   5.908959e-03 Rmax =   3.549713e+00 (On ne recalcule pas les forces en $\mathbf{x}^(1)$)
+</code>
-==== Nettoyage du critère
+On comprend directement l'intérêt de ne pas calculer deux fois la même chose !
+Le plus gros problème est qu'il faut garantir quelque soit le comportement des algorithmes utilisés pour la résolution d'un pas de temps, que ce flag soit dans un état cohérent, ce qui est loin d'être trivial vu le nombre de situation complexe à considérer. Pour se faire, j'ai supprimé ce flag de l'IterationManager et j'ai instancié une variable booléenne "forcesAreComputed" au niveau de la boucle d'intégration temporelle du schéma d'intégration (même niveau que la variable booléenne "rester"). Ainsi, j'ai fait passer en argument d'entrée aux fonctions iterationResolution, auxiliaryMethods, iterationInitialisation, skylineUpdate.
+<note important>Ce flag "forcesAreComputed" est uniquement utilisé à l'heure actuelle et à ma connaissance pour le line search !</note>
 ===== Fichiers ajoutés/supprimés ======