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/04/05 18:31] – [Nettoyage macOS] bomancommit:futur:robo [2018/07/31 18:12] boman
Line 1: Line 1:
 ====== Commit ====== ====== Commit ======
  
-===== Nettoyage VTK =====+===== Parallélisation du contact sur "faces complexes" =====
  
-Suite à la migration VTK6mon Metafor démarrait en plus de 6 secondes sur ma machine Ubuntu. Après une petite analyse, je me suis rendu compte que toutes les libs VTK de ma machine étaient chargées en mémoire suite à une opération de link un peu brutale (je linkais avec toutes les libs, c'est-à-dire ''VTK_LIBRARIES'')Comme les libs VTK d'Ubuntu sont très complètes (toutes les options sont activées), je me retrouvais ainsi avec plus de 300 libs ''.so'' à charger au démarrage, dont certaines utilisent MPI ou d'autres libs annexes un peu lourdes..+Étonnammentle 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 safeCeci à 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'').
  
-J'ai donc pris le temps de nettoyer tout ça et de sélectionner une à une les libs VTK qu'on utilise réellement dans Metafor. Le but est de linker Metafor qu'avec ce qui est réellement nécessaire.+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.
  
-Un seul petit problème rencontré (qui m'a pris une journée complète pour le résoudre)VTK6.2 d'Ubuntu ne charge pas correctement toutes les libs nécesaires à l'utilisation de ''vtkXYPlotActor'' etsi on ne linke pas explicitement avec ''vtkRenderingFreeType*'', on se retrouve avec une version de Metafor utilisable mais dont les fenêtres de courbes sont gelées. Est ce un bug VTK6.2 ou un bug Ubuntu, je n'en sais rien. La seule version de comparaison que j'ai est celle sous Windows linkée avec VTK7.1 et le bug n'est pas (plus?) présent.+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 pratiqueil 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.
  
-===== Nettoyage CMake 3.x =====+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'en ai profité pour gérer correctement les warnings liés aux nouvelles ''POLICY'' des CMakes récents. En effet, lorsque CMake change de comportement au cours des versions, les développeurs définissent une nouvelle ''POLICY'' qui, par défaut n'est pas définie (et produit un warning pour avertir les développeurs). Chaque policy peut valoir ''OLD'' (la valeur par défaut - mais qui traduit le "vieuxcomportement qui sera supprimé plus tard) et ''NEW'' (le nouveau comportement qui nécessite peut-être une phase de debug des ''CMakeLists.txt''. J'ai donc vaillamment activé toutes les nouvelles ''POLICY'' à ''NEW'' et... pas de fumée... ça a l'air de marcher.+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 "batteriepar 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!).
  
-Autre nettoyage: CMake gère maintenant de manière beaucoup plus transparente les opérations liées à ''moc'' (génération du code source supplémentaire des classes dérivées de Qt pour gérer le système de signaux/slots, pour ceux qui connaissent). J'étais passé à la nouvelle manière de traiter les mocs lors de la migration Qt5 mais cela générait des tas de warnings parce que je n'avais pas complètement supprimé l'ancienne manière de faire (il fallait supprimer tous les ''#include "machin.moc"'' qui sont maintenant vides. +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.
-Ce problème est maintenant corrigé.+
  
-===== Nettoyage images PNG =====+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.
  
-Le nouveau Qt est linké avec la toute nouvelle libpng qui détecte et signale des erreurs dans les profils de couleur sRGB de certaines images PNG. On voit ces nouveaux warnings au runtime dans la console. J'ai donc passé tous les PNG du repository à travers [[https://psydk.org/pngoptimizer?lang=fr|PngOptimizer]]. Ça a supprimé tous les warnings et, accessoirement, ça a réduit la taille de quelques uns de ces fichiers.+===== 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)
  
-===== Nettoyage macOS =====+===== Commit David Thomas =====
  
-J'ai continué la compilation [[wp>macOS]] (il parait qu'on ne dit plus "OSX", ni "Mac OS" mais "macOS") sur le mac du service nommé ''spirou''. J'arrive maintenant à tout compiler (j'ai ajouté parasolid, MUMPS, oo_nda) et ça tourne plutôt bien (les perfs sont assez bonnes, voire très bonnes)Pour fêter çaj'ai défini un ''CMake/macos.cmake'' (config de compilation complète) et ''CMake/macos-student.cmake'' (config de compilation sans oo_nda, ni parasolid)+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 calculEn effetdans 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: 
-J'ai supprimé ''CMake/OSX-student.cmake'' qui n'est plus utile.+  tsm.setVerbose(False)
  
-Autre amélioration sous Mac: l'aspect de la fenêtre graphique principale de Metafor était très moche sur Mac dû à un mauvais choix de police de caractère. J'avais eu le même problème sous Ubuntu où j'avais dû trouver une police pas trop laide qui existait sous Windows et Linux. Ce problème a été résolu dans Qt 5.2: j'utilise ce nouveau système et j'ai donc changé la manière dont les polices de type "monospace" sont choisies. Le rendu est maintenant "parfait" sur toutes les plateformes (si on utilise Qt 5.2). C'est la police "monospace" du système qui est choisie (et qui dépend donc de votre "thème" de bureau). 
  
- --- //[[r.boman@ulg.ac.be|boman]] 2017/04/04 16:35//+===== 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