Differences

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

--- commit:futur:robo [2017/09/06 14:05] – boman
+++ commit:futur:robo [2018/07/31 18:12] – boman
@@ Line 1: / Line 1: @@
 ====== Commit ======
-===== Portabilité =====
+===== Parallélisation du contact sur "faces complexes" =====
-Le code ne compilait plus sous macOS et sous Windows-x86 (MinGW). Ces deux types de compilation ne sont pas testées dans la procédure de batterie et il faut donc régulièrement corriger les sources d'incompatibilité.
+É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 et dans la classe ''Curve'' en vue d'un calcul d'intersections multiples (''Curve::multipleIntersection'').
-Sous macOS, le problème venait des nouveaux templates de Gaetan permettant d'effectuer une intégration (''AdaptiveClenshawCurtisIntegratorTemplate'' et classes associées). Il y avait plusieurs problèmes dans ces fichiers liés à l'instanciation explicite de certaines instances. J'ai mid le code sous la forme de celui qui compile sans problème mais malgré ça, j'ai dû définir certaines fonctions "inline" pour que clang les retrouve. Je n'ai pas tout compris.
+Supprimer ces variables statiques entraîne une allocation (coûteuse) des objets à chaque passage dans la routine et une dégradation énorme des perfs. Je n'ai pas gardé les chiffres précis lorsque j'ai testé de supprimer brutalement ces attributs "static", mais on obtient un temps CPU doublé voire triplé sur le S-Rail.
-Ceci m'amène à conclure qu'il faut vraiment essayer de limiter l'utilisation des templates au minimum dans Metafor. C'est une vraie source de problème. Le problème des templates Metafor est qu'il s'agit souvent de templates un peu pourris dont une grande partie des fonctions doit être spécialisée pour un argument donné (dimension dans les éléments). Autrement dit, le template n'est valable que pour un nombre très restreint de paramètres (2D, 3D p expl) et en ajouter un nouveau nécessiterait la réimplémentation de plusieurs fonctions. Ne faites donc pas de nouveaux templates pour le plaisir d'en faire; c'est un vrai casse tête de rendre portable ce type de code.
+Je me suis donc dit qu'il serait peut être inétressant de tester une "nouvelle" fonctionnalité de TBB: le [[https://www.threadingbuildingblocks.org/tutorial-intel-tbb-thread-local-storage|thread local storage]] (TLS). Il s'agit 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 de la variable statique qui est donc dupliquée pour chaque thread et d'éviter ainsi les conflits entre threads.
-Avec MinGW, le problème venait des nouvelles classes de Linesearch de Gaetan. Il y a beaucoup de trucs un peu louches dans ces classes: ''const double &'' au lieu de ''double'', fonctions virtuelles dans des classes sans dérivation (ou l'inverse), double dérivations étonnantes, etc. ce qui posait problème était la spécification dllimport/dllexport de fonctions inline (ça n'a pas de sens). J'ai supprimé ces mots clefs. J'en ai profité pour remettre en forme ces fichiers (même l'indentation était pourrie).
+Cette manière de faire est la manière "quick & dirty" de paralléliser des variables statiques. Bien que ça soit la manière qui vienne immédiatement à l'esprit, ce n'est pas la manière à privilégier (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 vérifié la compilation sur fabulous, qui n'est pas testée elle non plus.
+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. Ces bonnes perfs s'expliquent peut-être aussi parce que j'ai supprimé certaines opérations inutiles dans les routines (calcul du numéro de courbe max à chaque passage pour l'assigner aux courbes temporaires!).
- --- //[[r.boman@ulg.ac.be|boman]] 2017/09/06 13:57//
+Par contre, le "thread 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 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, où les 2 versions coexistent pour des raisons linuxiennes)
+===== Commit David Thomas =====
+J'ai récupéré la version Metafor de David Thomas avant qu'il parte pour commiter ses modifs utilisées pour le couplage SU2-Metafor. Il s'agit principalement d'une option du ''TimeStepManager'' qui permet de ne pas afficher les temps d'archivage à l'écran au démarrage d'un calcul. En effet, dans le cas d'un calcul de couplage, il peut y en avoir beaucoup et on se retrouve avec une quantité impressionnante d'infos inutiles dans le fichier de sortie. Pour l'utiliser:
+  tsm.setVerbose(False)
+===== gmsh.py =====
+L'import gmsh sort maintenant un message d'erreur compréhensible quand un ''.geo'' est spécifié mais non présent (gmsh ne fait pas cette vérification et crée un nouveau maillage... vide).
+===== meshingTools.py =====
+J'ai ajouté une fonction de fusion d'ugrid VTK pour permettre le maillage des "tresses" de Cédric Laurent, un test qu'il n'a jamais commité et que j'ai retrouvé en fouillant ses backups en triant le fouillis du NAS. Je le commiterai plus tard (il nécessite "un peu" de nettoyage et la définition d'extracteurs pertinents).
+ --- //[[r.boman@ulg.ac.be|boman]] 2018/07/31 17:39//