Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2009:02_26

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
commit:2009:02_26 [2009/02/26 08:37] bomancommit:2009:02_26 [2016/03/30 15:23] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +====== 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.
 +
 +{{ :commit:2009:easresidual.png |}}
 +
 +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!!
 +
 +{{:commit:2009:easzb1.png?300|Figure #1 - Solution Line-search}} {{:commit:2009:easzb2.jpg?300|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:__
 +<code>
 +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
 +</code>
 +
 +__Un test EAS sur maillage non uniforme:__ 
 +<code>
 +apps/ale/testConv2Dmesh.py added
 +</code>
 +
 + --- //[[r_boman@yahoo.fr|Romain BOMAN]] 2009/02/26 08:36//
  

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki