Differences

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

--- commit:2018:01_06 [2018/01/06 22:33] – [LineSearch - Initial Balancing et IterationResolution] wautelet
+++ commit:2018:01_06 [2018/01/09 22:53] (current) – wautelet
@@ Line 2: / Line 2: @@
 Ce commit est pour un petit nettoyage de la routine IterationResolution.
-==== IterationResolution ====
-J'ai fait entré la ligne de code im.incrementIterationNo() dans le "if/else im.getMaxNbOfIterationsReached()", ce qui est beaucoup plus cohérent !
-J'ai commentarisé la ligne de commande  "this->metafor.getDomain().getEqualityDofConstraintsSet().impose();" car ceci est fait plus bas suite à la routine dofsCorrections().
-J'ai formalisé la sortie du Line Search comme les itérations mécaniques : notations scientifiques sous forme exponentielle.
 ==== LineSearch - Initial Balancing et IterationResolution ====
-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$ .
+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.
 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)$  :
@@ Line 23: / Line 15: @@
  $res_{LS} \left(0 \right) = \mathbf{F}^{OOB}\left(\mathbf{x}^{(i)} \right)  . \mathbf{\Delta x}^{(i)}$
-Puisque la direction de recherche  $\mathbf{\Delta x^{(i)}$  respecte la relation suivante :
+Puisque la direction de recherche $\mathbf{\Delta x}^{(i)}$ respecte la relation suivante :
- $\mathbf{K}_{T}^(i) \mathbf{\Delta x^{(i)} = - \mathbf{F}^{{OOB}^{(i)}}$
-Ainsi, nous avons que le résidu du line search est négatif si la matrice de raideur tangente est définie positive.
+ $\mathbf{K}_{T}^{(i)} . \mathbf{\Delta x}^{(i)} = - \mathbf{F}^{{OOB}^{(i)}}$
+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 à
+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
+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>
 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ée 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.
+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 ======