Commit 2008-12-02

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

• Possibilité de définir un chargement incrémental (UniformLoading avec INCREMENTAL_LOAD) par python. Auparavant, ce genre de chargement n'était disponible qu'en TOTAL_LOAD ce qui empêchait son utilisation en ALE. Un exemple d'utilisation est disponible dans ale.rotAnneau2 où une expansion radiale suivie d'une rotation est codée en python.

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

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