Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2009:02_26

Commit 2009-02-26

Modifs

EAS

J'ai travaillé sur l'EAS pour essayer de comprendre pourquoi mes tests ALE merdouillent quand on mixe des éléments de tailles différentes les uns à côté des autres. C'est ennuyeux puisque un gain CPU en ALE ne peut se faire qu'en raffinant et déraffinant le maillage. On doit faire ainsi cohabiter des grandes mailles avec des très petites au sein du même maillage. Ce problème, qui n'a rien à voir avec l'ALE, me force à utiliser des maillages inutilement fin en ALE + EAS et au final, l'ALE perd un peu son intérêt.

J'ai essayé de comprendre pourquoi ça plante en traçant l'évolution du résidu (norme des forces internes EAS) dans la direction donnée par le N-R à chaque itération lors du calcul des forces internes d'un élément qui explose.

Clairement, on arrivera jamais à atteindre un minimum du résidu à partir de cette config avec un N-R. J'ai donc ajouté un line-search pour converger malgré tout.

Modifs:

  • Ajout d'un line-search dans la routine de calcul des forces internes EAS dans le but d'essayer d'éviter les Jacobiens négatifs en série qui apparaissent souvent quand on utilise ces éléments.
  • Création d'une classe générique LineSearch dans mtMath. J'ai codé un algo de Fleury pour minimiser une fonction lorsqu'on ne sait que l'évaluer. Dans ce cas-ci, on essaye de minimiser la norme du résidu des forces internes EAS. J'ai profité de ce développement pour tester l'écriture d'un algo “générique” dont nous pourrons nous inspirer pour remplacer par exemple tous les N-R qui trainent dans le code. L'idée est simple: on définit une fonction qui va évaluer ce qu'on veut line-searchiser:
EasLSFunction<DIM> fct(*this, easModesFactors1,
                       easModesElement->getDeltaAlpha(),
                       GPM0, GPM1, GPM0_v, GPM1_v,
                       easModesElement->getForceEnh(),
                       volumElementShcut);

cette fonction sera appellée par l'algo via un appel virtuel fct.eval(x). Reste à executer le line-serach de Fleury (en 2 lignes!):

LineSearch linesearch(fct, 0.1);
double alpha = linesearch.execute();
  • L'algo commence par un N-R classique. S'il ne converge pas (soit à cause d'un jacobien négatif ou un nombre d'itérations max atteint), la boucle est redémarrée pour l'élément problématique avec un line search à chaque ité de N-R. Pour ce line-search, le nombre d'ités max est multiplié par 10.
  • En pratique, on arrive à converger beaucoup mieux et éviter ainsi des divisions de pas de temps. Mais, malheureusement, ce n'est pas la solution définitive aux comportements bizarres des EAS. En particulier, j'aurais pu très facilement définir de nouveaux easZarbi.py pour la batterie. C'est le cas par exemple de apps.monoMeca.eas3dNum qui consiste à faire une traction puis une compression sur un mono encastré. On s'attend à une réponse finale en losange (grande base à l'opposé de l'encastrement - figure #2 ci-dessous) avec une conservation de volume… Mon line-search semble converger vers une solution différente (un losange inversé où il y a visiblement une perte de volume - figure #1 ci-dessous). Après debug, je me suis rendu compte que la version sans line-search peut également converger vers cette solution bizarre si on augmente le nombre maximum admissible d'itérations!!

Figure #1 - Solution Line-search Figure #2 - Solution OFFI

Pour éviter ce genre de problème, Luc a eu l'idée de ne plus permettre des valeurs de mode EAS trop importantes. Les modes étant des incréments sur un pas de temps, on peut sans problème faire une division de pas de temps si la valeur d'un mode devient trop importante. Pour pouvoir jouer avec ça, j'ai ajouté un paramètre à l'élément EAS (MAXFEAS).

En résumé: 2 nouveaux paramètres:

Nom type défaut
MAXFEAS double 1.0 division du pas si un mode dépasse cette valeur
LSEAS bool true active/désactive le line-search

ALE

  • Recalcul du “J1 centre EAS” après convection. Ca permet d'avoir le bon J0centre au pas suivant.
  • Ajout d'une vérification (facultative) du caractère déviatorique du déviateur des contraintes après convection. Par défaut, la totalité du déviateur du tenseur contrainte est convectée. Pour limiter les calcul en 2D, on peut ignorer les compos Z:
region.ignore(IF_SIG_XZ)
region.ignore(IF_SIG_YZ)
region.ignore(IF_DEV_SIG_ZZ) 

A ce moment, il faut alors recalculer la compo ZZ qui est tout de même utile pour calculer le J2.

ale.getPostStep().getConfig().setSigZZ(SIGZEQ_COMPUTE)

En 3D, on peut s'amuser à supprimer la trace du déviateur convecté (dans ce cas, il faut bien sûr convecter toutes les composantes):

ale.getPostStep().getConfig().setSigZZ(SIGZEQ_TRUNCATE)

Visu

  • Le destructeur de VizWin détruit maintenant la fenêtre. Ceci évite de manipuler une fenêtre dont les composants sont détruits (et éviter un crash - merci au TFiste “tubet”).
  • Ajout d'un win.close() qui cache la fenêtre (réouverture avec win.open())
  • Les lignes maillées sont maintenant affichées via leur maillage et se déforment au cours du temps. En pratique, ça évite les lignes pourries qui traversent l'affichage, les cercles qui se déforment n'importe comment pendant le calcul, etc.

Autres

  • Batterie multi-thread: je suis revenu a l'ancienne manière de faire qui freeze moins.
  • Suppression d'un warning dans le CMakeList.txt de stp2e.

Projet

N'oubliez pas de re-swigifier vos wraps.

Fichiers ajoutés/supprimés

Source:

File	Text status
mtElements/volumes/methods/EasInfo.h	added
mtElements/volumes/methods/EasInfo.cpp	added
mtElements/volumes/methods/EasLSFunction.h	added
mtElements/volumes/methods/EasLSFunction.cpp	added
mtElements/volumes/methods/EasCauchyMechVolIntegMeth.inl	deleted
mtElements/volumes/methods/EasCauchyMechVolIntegMeth.cpp	added (+)
mtFEMBase/EndALEConfig.cpp	added
mtFEMBase/EndALEConfig.h	added
mtMath/LineSearch.h	added
mtMath/LineSearch.cpp	added

Un test EAS sur maillage non uniforme:

apps/ale/testConv2Dmesh.py	added

Romain BOMAN 2009/02/26 08:36

commit/2009/02_26.txt · Last modified: 2016/03/30 15:23 (external edit)