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!!

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:

• 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)

• 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.

• 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.

N'oubliez pas de re-swigifier vos wraps.

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