Table of Contents
Commit 2008-12-02
Modifs
ALE - convection
- Modification du schéma du 2nd ordre au niveau de la prise en compte des CL. Les flux parasites sur les frontières sont maintenant gérés comme pour le schéma du 1er ordre. Ceci permet d'appliquer facilement des CL de traction sur des frontières eulériennes. L'imposition des CL n'est en général jamais requise sauf pour qq tests de la batterie.
- Nouveau calcul du flux géométrique pour la convection ALE. La nouvelle formulation entraîne un flux nul lorsqu'une arête glisse le long d'un cercle. Cette manière de faire est indispensable pour éviter les flux parasites lors des rotations avec le schéma du 2nd ordre.
- Correction d'un bug dans le limiteur de Barth (deux boucles “
for(int i
” imbriquées!). - Correction d'un bug énorme dans le VF à reconstruction linéaire (
getRemeshedVolume
retournait le volume lagrangien!). Ce bug n'affectait que très peu la méthode de Godunov qui n'utilise pas directement l'aire remaillée (mais plutôt l'aire lagrangienne moins la somme des flux géométriques). - Suppression de la convection des grandeurs 3D en 2D EPD.
Chargements incrémentaux en "python"
- Possibilité de définir un chargement incrémental (
UniformLoading
avecINCREMENTAL_LOAD
) par python. Auparavant, ce genre de chargement n'était disponible qu'enTOTAL_LOAD
ce qui empêchait son utilisation en ALE. Un exemple d'utilisation est disponible dansale.rotAnneau2
où une expansion radiale suivie d'une rotation est codée en python.
Optimisation de getPos
Après avoir corrigé et amélioré l'algo de convection ALE, je me suis rendu compte que son utilisation allait être problématique: Sur un test 2D, l'ALE prend plus de 80% du temps de calcul total! En regardant de plus près, on remarque (merci AQtime) que le gros point faible est la fonction getPos
qui retourne simplement les positions nodales. L'ALE utilise intensivement la géométrie et manipule les positions dans toutes les routines. Au final, plus de 40% du temps est passé à récupérer des positions! A coté de ça, on constate que de nombreux accès DB sont aussi très lents. Il était donc indispensable d'améliorer ça pour pouvoir montrer l'intérêt de l'ALE sur le lagrangien. J'ai regardé comment les accès vers les positions étaient faites dans l'élément puisque celui-ci ne fait aucun “getPos
”! L'élément utilise une vieille opti de Ludo qui consiste à stocker des pointeurs directs vers la DB dans un objet séparé nommé PointersToSets
. Cette classe est manipulée “de l'extérieur” par l'élément. Je me suis donc dit qu'il suffisait d'encapsuler cette méthode dans les points pour en faire bénéficier toute la géométrie.
Les points/noeuds actuels ont 2 états: soit ils sont liés à une DB, soit ils sont “libres”. Le cas “libre”, géré par la variable keep_pos
, ne nous intéresse pas ici. Quand un point est lié à la DB, il récupère ses coordonnées via un findDBObject
très coûteux. Cet appel est maintenant court-circuité par un appel à PointersToSets
. Cet objet est un objet unique par Analyse. Il est géré entièrement par l'Analyse vu que l'Analyse gère la DB et, en particulier, le PointersToSet de l'Analyse est mis à jour lors de chaque setStep
.
Au final, un gain de près de 30% sur mes tests ALE utilisant le schéma du 2nd ordre. Par contre, le temps total de la batterie sur gaston a même un peu augmenté (je vois pas comment c'est possible mis a part que Luc tournait des batteries en même temps que moi). Sur spirou, je gagne 2%.
Projet
Fichiers ajoutés/supprimés
mtALE/DummyStencil.cpp added mtKernel/PointersToSets.cpp added (+) mtALE/DummyStencil.h added mtKernel/PointersToSets.h added (+) mtKernel/PointersToSets.inl added (+) mtFEM/PointersToSets.cpp deleted mtFEM/PointersToSets.h deleted mtFEM/PointersToSets.inl deleted
— Romain BOMAN 2008/12/02 10:09