Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2018:01_06

Commit 2018-01-06

Ce commit est pour un petit nettoyage de la routine IterationResolution.

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$ 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)$ :

$$ res_{LS} \left(\alpha \right) = \mathbf{F}^{OOB}\left(\mathbf{x}^{(i)}+\alpha \mathbf{\Delta x}^{(i)} \right) . \mathbf{\Delta x}^{(i)} $$

Dans le cas échéant où $\alpha = 0$, nous avons que

$$ 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 :

$$\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)} $$

Ceci permet de clarifier la remarque de Luc dans iterationResolution() :
            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");
            }

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 :

 *** 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)$)

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.

Ce flag “forcesAreComputed” est uniquement utilisé à l'heure actuelle et à ma connaissance pour le line search !

Fichiers ajoutés/supprimés

[a]:
[r]:

Cas tests ajoutés/supprimés

[a]:
[r]:

gaëtan 2017/01/06 20:00

commit/2018/01_06.txt · Last modified: 2018/01/09 22:53 by wautelet