Differences

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

--- commit:futur:robo [2018/07/31 17:34] – boman
+++ commit:futur:robo [2019/07/10 14:43] (current) – boman
@@ Line 1: / Line 1: @@
 ====== Commit ======
-===== Parallélisation contact "faces complexes" =====
+===== VizWin/BWin Linux =====
-É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 des intersections multiples (''Curve::multipleIntersection'').
+Lorsqu'on utilise Metafor sous Linux, on se rend compte que le développement a été effectué sous Windows. Les widgets de 'BWin', par exemple, ont été dimensionnés (en dur) suivant la largeur de la police de caractère de Windows. On se retrouve alors avec des widgets "trop étroits" sous Ubuntu qui utilise une police plus large.
-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é, mais c'est de l'ordre d'un temps CPU doublé voire triplé sur le S-Rail.
+{{:commit:2019:bwin_avant2.png?300|avant}} {{:commit:2019:bwin_apres.png?300|après}}
-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.
+J'ai donc passé sur tous les widgets pour effacer toutes ces tailles fixées "en dur".
-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.
+Un autre problème sous Ubuntu est l'ouverture des fenêtres 'VizWin'. Elles s'ouvrent par moment avec une taille ridicule qui correspond à la taille de la fenêtre VizWin dans le QtDesigner. Normalement VizWin doit s'afficher et se redimensionner soit à la taille par défaut, soit à la taille qui a été sauvegardée précédemment. Cette opération de redimensionnement se passe mal sur le bureau Gnome et je suspecte une interaction non voulue entre cette opération de redimensionnement et les effets de bureau de Gnome où les fenêtres n'apparaissent pas d'un seul coup. Un autre facteur qui ne vient pas aider est le fait que, dans Metafor, l'interface graphique est dans un thread séparé, piloté par le thread python via des requêtes inter-threads dont je ne connais pas les détails techniques.
-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.
+J'ai essayé de jouer sur plusieurs plans pour obtenir un bon redimensionnement. Au final, ça marche beaucoup mieux qu'avant mais ça ne marche pas toujours. J'ai donc simplement augmenté la taille de VizWin dans le QtDesigner pour que, quand ça foire, la fenêtre ne soit pas minuscule.
-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.
+===== ProjectionSelector =====
-===== Compilation avec un double python 2/3 =====
+Les cas tests de redressage pour Minitubes nécessitent l'utilisation de l'ancien projection selector codé par Ludo sur base du travail de Denis Graillet. En effet, le nouvel algorithme de Gaëtan provoque des mauvaises projections qui ne sont clairement pas normales à la surface. Le problème avec l'ancien algorithme, c'est qu'il affiche, dans certains cas pathologiques, des infos pour dire qu'il ne s'en sort plus dans le choix des projections multiples et qu'il choisit alors la première. Ces infos sont tellement courantes dans les tests de redressage (2 tubes maillés qui sont en contact l'un dans l'autre), que le fichier de sortie devient énorme.
-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)
+J'ai donc simplement supprimé l'affichage de ces warnings (ils sont connus et ne servent que si quelqu'un voulait débuguer le truc)
-===== Commit David Thomas =====
-J'ai récupéré la version Metafor de David Thomas 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é d'infos inutiles impressionnante dans le fichier de sortie.
+===== Tabs/Espaces =====
-===== gmsh.py =====
+J'ai supprimé les tabs qui avaient été ajoutés lors de commits précédents (principalement par Gaëtan).
-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 le test et crée un 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.
- --- //[[r.boman@ulg.ac.be|boman]] 2017/10/16 08:55//
+ --- //[[r.boman@ulg.ac.be|boman]] 2019/07/10 14:27//