Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:futur:robo

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
Last revisionBoth sides next revision
commit:futur:robo [2017/03/13 16:47] bomancommit:futur:robo [2018/07/31 18:12] boman
Line 1: Line 1:
 ====== Commit ====== ====== Commit ======
  
-====== Portage Visual Studio 2015 ======+===== Parallélisation du contact sur "faces complexes" =====
  
-Comme je l'avais dit dans mes précédents commitsJe travaille depuis un bon bout de temps sur la mise à jour des bibliothèques & compilateurs utilisés par MetaforPour rappel, les buts sont les suivants: +Étonnammentle S-Rail de la batterie de test ne pouvait pas être lancé en parallèleAprès debugje 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 "statiquesdans ces classes et dans la classe ''Curve'' en vue d'un calcul d'intersections multiples (''Curve::multipleIntersection'').
-  * **Compilation de Metafor sous MacOSX:** MacOS nécessite les versions les plus récentes de VTK et Qt pour fonctionner correctement. En particulier les versions de VTK et Qt qu'on utilisait n'étaient plus compilables depuis la mise à jour "Sierra"+
-  * **Utilisation du C++11 / C++14:** à ce niveau, nous étions limités par le compilateur le plus vieux parmi ceux qu'on utilise sur toutes les machines, c'est-à-dire le compilateur Visual Studio 2012 qui ne supporte que quelques nouvelles fonctionnalités C++11 (auto, fonctions lambdas basiques, etc.).+
  
-J'ai donc porté le code pour utiliser le Visual Studio 2015 et j'en ai profité pour mettre à jour toutes mes libs. Le code est donc compilable avec les toutes dernières versions de toutes les bibliothèquessauf python qui reste en 2.7.x. La migration vers python 3 sera effectuée plus tard (c'est un travail énorme).+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.
  
-Le Visual Studio 2017 est sorti la semaine passée mais n'est pas encore utilisable (à cause de Parasolid entre autres qui ne le supporte pas encore) +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.
  
-Le code reste évidemment compilable avec Visual Studio 2012.+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.
  
-En pratique, voici les versions utilisées sur mon PC: +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!).
-  * **Visual Studio 2015 Community:** appelé aussi "VS14" ou "msvc19". Supporte le C++11 et est gratuit! voir [[https://www.visualstudio.com/fr/downloads/|site microsoft]]. La version 2015, qui est difficile à trouver depuis la mise à jour 2017, est conservée sur le NAS. Au niveau du code source, tout a compilé du premier coup, sauf la visu des outils Abrawal où le compilateur ne s'en sort pas de manière assez étonnante (j'ai dû ajouter des accolades {} autour d'un bloc ''for'' alors que celles-ci ne sont pas nécessaires). +
-  * **Intel Parallel Studio 2017 Update 2 (MKL, TBB):** On a maintenant la possibilité d'utiliser TBB comme threading model avec le Pardiso (à tester!).   +
-  * **zlib 1.2.11:** rien de neuf, mis à part des bug fixes. +
-  * **python 2.7.13+:** compilable grâce au travail de [[https://github.com/kovidgoyal/cpython|Kovid Goyal]], le développeur principal de Calibre,  qui maintient la compatibilité VS14 au fil des versions de python. Sans lui, je ne sais pas comment j'aurais fait pour éviter la migration python 3. +
-  * **CMake 3.7.2:** génère de nombreux warnings qu'il faudra traiter correctement (je ne l'ai pas encore fait - j'attends que tout le monde ait migré). +
-  * **Qt 5.8.0:** compatible avec notre nouveau code Qt 5.6.x (voir mes commits précédents). L'avantage d'utiliser cette version est qu'on peut maintenant simplement installer les binaires Qt à partir de l'installeur officiel (sauf sous Mac où l'installeur officiel freeze - no comment) +
-  * **VTK 7.1.0:** petits problèmes de changement de syntaxe dans les tests "longBone". J'ai également corrigé un problème de création des lumières de la scène 3D. A part ça, le gros changement de VTK7 par rapport à VTK6 est le support d'un OpenGL récent (l'option ''VTK_RENDERNING_BACKEND'' vaut ''OpenGL2'' par défaut, ce qui correspond à de l'OpenGL 3.4 si j'ai bien compris) qui devrait améliorer grandement les perfs générales de VTK. En particulier, tous les glyphs devraient être rendus à l'aide de vertex shaders au niveau du GPU. Malheureusement (pour moi) cette nouvelle implémentation moderne n'est pas utilisable sous Virtualbox qui ne gère que de l'OpenGL 1.1. J'ai donc dû compiler 2 versions; une pour ma VBox sous linux à l'ULg et une pour ma machine Windows à la maison. +
-  * **SWIG 3.0.12:** aucun problème. +
-  * **Parasolid 29.1:** dernière version en date. Visual Studio 2012 nous bloquait définitivement à la v28.1. On espère obtenir les projections parallèles en restant à jour (c'est peut-être déjà OK avec cette nouvelle version? j'ai pas testé)+
-  * **numpy 1.11.2 + dépendances:** compilent comme un charme avec tous ces outils récents.+
  
-Evidemmentil y a toutes sortes de petits "trucspour construire les libs (la liste est très courte par rapport à ce qu'il fallait savoir avant). J'ai fait un mémo que je donnerai à Luc lorsqu'il aura le temps de migrer ses libs. D'ici là, ne changez pas de compilateur à moins que vous vouliez compiler votre propre set de libs+Par contrele "thread local storagepermet 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.
  
-Une fois que tout le monde aura migré vers VS14 on pourra envisager de supprimer le vieux code VTK5 / Qt4 (après update des stations) et on pourra nettoyer pas mal de choses (boucles peu lisibles utilisant explicitement des itérateurs par exemple) avec le C++11.+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 MacOSX ======+===== Compilation avec un double python 2/3 =====
  
-  * Correction mineure du code source (un ''inline'' en trop dans un fichier CPP qui provoquait un "unresolved" avec ''clang''). +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 versions coexistent pour des raisons linuxiennes)
-  * Problème de l'écran Retina de l'iMac du serviceLe widget Qt-VTK ne supporte pas ce "nouveau" type d'écran haute résolutionL'image est dessinée dans le quart inférieur gauche de la fenêtre graphique. Pour résoudre le problème j'ai dû ajouter un appel vers une fonction ObjectiveC qui désactive explicitement la haute résolution de la fenêtre (''mtQt/osxHelper.mm''). J'espère que ce problème sera résolu dans les prochaines versions de VTK.+
  
 +===== 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//
  
commit/futur/robo.txt · Last modified: 2019/07/10 14:43 by boman

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki