This is an old revision of the document!
Table of Contents
Commit
Parallélisation contact faces complexes
Étonnamment, le S-Rail de la batterie de test ne pouvait pas être lancé en parallèle. Après debug, je me suis rendu compte que les classes SurrondednessTest2D et TriangleSurrondednessTest n'étaient pas thread safe. Ceci à cause d'objets géométriques temporaires qui sont définis “statiques” dans ces classes. Supprimer ces variables statiques entraîne une allocation des objets à chaque passage dans la routine et une dégradation énorme des perfs (je n'ai pas gardé les chiffres précis mais c'est de l'ordre d'un temps CPU doublé voire triplé sur le S-Rail).
Je me suis donc dit qu'il serait peut être inétressant de tester une “nouvelle” fonctionnalité de TBB: le “thread local storage”. il s'agit en fait de permettre à chaque thread de créer ses propres variables statiques. En pratique, il s'agit d'une sorte de map qui permet à chaque thread de récupérer son instance particulière et d'éviter ainsi les conflits.
Cette manière de faire est la manière “quick&dirty” de paralléliser des variables statiques. Ce n'est donc pas une manière à conseiller (cfr nettoyage actuel des matériaux), mais dans des cas bien particuliers comme celui-ci (le suroundedness test du contact), c'est l'occasion de voir ce que ce système vaut.
J'ai donc implémenté ça et les résultats sont plutôt bons puisque le S-Rail ne se voit pénalisé que d'1s sur 53s du test “batterie” par l'ajout de ces maps TBB quand on lance le test en série. Par contre, le thraed local storage permet de lancer le modèle en parallèle et d'obtenir un speedup appréciable: 157s sur 6 threads pour l'emboutissage complet au lieu de 446s sur 1 thread pour la version 1 série.
Entretemps, j'ai appris que Gaëtan avait réécrit un S-Rail dont la géométrie n'utilise plus de surrundedness test, c'est-à-dire avec uniquement des patchs de Coons. Ce test n'est pas commité alors qu'il permet de simuler également le retour élastique. Je le commiterai plus tard.
Compilation avec un double python 2/3
J'ai adapté les CMakeLists.txt pour que Metafor cherche exclusivement python 2.7 et ne trouve pas un éventuel python 3.x installé sur la machine (la mienne, en particulier)
— boman 2017/10/16 08:55