Pour être certain que mes développements précédents relatifs au portage VTK5 ⇒ VTK6 et Qt4 ⇒ Qt5 continuent à fonctionner commits après commits, il semble nécessaire que la batterie soit dorénavant passée avec au moins une machine utilisant les nouvelles versions des libs vtk6/qt5.

Luc n'ayant pas le temps de migrer ses libs Windows actuellement, nous avons décidé de migrer la seule machine linux qui permette aujourd'hui d'installer vtk6/qt5 dans la liste de ses packages précompilés. Je ne parle évidemment pas de fabulous mais de gaston.

Gaston tourne en “Debian pas trop vieux” (Debian 8 jessie) et propose un VTK 6.1.0 et un Qt 5.3.2. ces versions sont un peu vieilles mais elles possèdent tous les changements d'API problématiques. J'ai donc installé ces 2 sets de packages ainsi que PyQt5 et python-vtk6 pour pouvoir faire tourner la batterie. Enfin, j'ai désinstallé les versions de vtk5/qt4.

Lors de la génération des makefiles par cmake, il y a un petit paquet de warnings dus au fait que le cmake est très vieux (3.0.2) et que le découpage de VTK en packages de debian n'est pas parfaite (j'ai l'impression qu'ils ont eu du mal à découper la libs en plusieurs packages et il reste des crasses dans le VTKConfig.cmake).

Bien sûr, une fois compilé, Metafor n'a pas fonctionné directement: vtk6 m'a d'abord fait des cores à tout bout de champ. En investiguant, j'ai vu que même ma version ubuntu que j'utilise depuis un petit mois sur mon PC, qui tournait avant sans problème, ne fonctionnait plus! Il s'agissait en fait d'un problème de timing d'ouverture des fenêtres. En effet, je travaille aujourd'hui de chez moi et l'initialisation de VTK prend donc beaucoup de temps (affichage distant X via Tunnel SSH sur Teamviewer à travers le VPN de l'ULg). L'initialisation de la ScalarBar de VizWin utilise une nouvelle fonctionnalité de VTK6 qui, si elle est compilée (ce n'est pas le cas sous Windows), permet l'affichage des expressions mathématiques par des appels à matplotlib. “Mais matplotlib n'est-il pas une lib python à la base?” allez-vous me dire. Et bien oui, c'est dingue mais c'est comme ça! VTK initialise un interpréteur python au beau milieu de son C++ pour appeler matplotlib et afficher des caractères à la LaTeX! Qu'il trouve matplotlib ou pas, le mal est fait: dans le cas de l'architecture de Metafor, un second interpréteur est démarré par VTK dans le thread graphique, en parallele à celui dans le thread principal de calcul. Il faudrait donc idéalement que VTK acquière la “GIL” (Global Interpreter Lock) de python… ce qui n'est fait que dans les sources VTK7.

Comment m'y suis-je pris pour contourner le problème sans recompiler VTK7 ou patcher des sources de VTK6 ou recompiler VTK6 sans matplotlib? En fait, je me suis rendu compte que cette fonctionnalité n'est appelée que via une surcharge (“override”) d'une classe classique de VTK. La surcharge est gérée par une factory VTK (vtkObjectFactory). J'ai donc désactivé la surcharge directement au niveau de la factory, juste avant de créer une scalarbar dans Metafor! C'est pas très propre mais au moins la solution est juste à côté du problème dans le code source. Ça marche très bien dans tous les cas, même quand la classe appelant matplotlib est inconnue au bataillon (VTK5 ou VTK6 sans matplotlib).

Qui n'a jamais pesté sur le longbone? (parmi ceux qui commitent). Et bien, lisez ce qui suit: je crois que j'ai résolu le “problème”.

Longbone est un test biomec de Cédric Laurent qui consiste à charger en compression un os réparé avec une plaque et des vis. Une variante avec une tige longitudinale métallique existe mais elle fait moins parler d'elle.

Le longbone est un test qui plante un peu aléatoirement. Quand il plante il faut le relancer… et le relancer… jusqu'à ce que ça marche.

La résolution de ce bug est donc un effet bénéfique du portage vtk6/qt5. Voici toute l'histoire: j'ai d'abord voulu utiliser ma machine perso ubuntu pour faire passer une batterie complète en vtk6/qt5. Les cas-tests biomecs, écrits en python-vtk m'ont évidemment posé des gros soucis. Outre les problèmes liés au portage vers VTK6, le plus gros est venu de tetgen qui ne voulait pas marcher correctement sur ma machine. Tetgen plantait à tire larigot dans 3 tests et pas possible d'obtenir des résultats alors que tout marche correctement ailleurs. Le problème venait de la manière dont j'avais compilé tetgen sous ubuntu. Finalement il faut retenir que tetgen est un programme composé de 2 fichiers sources dont le premier doit impérativement être compilé en debug (-O0) et le second impérativement en release (du moins sans les assertions - macro NDEBUG active)… Si on ne suit pas ces recommendations, ça marche… parfois… en fonction du compilateur et de l'humeur de la machine.

Après avoir réglé le problème tetgen, un seul test me résistait encore: le longbone qui plantait systématiquement lors du passage dans une routine de “nettoyage manuel” de Cédric (d'un côté j'avais progressé puisqu'il ne plantait plus aléatoirement!). Pour gagner du temps, j'aurais dû partir du principe que la routine était “un peu” bâclée et donc certainement boguée mais j'ai très longtemps cru que c'était VTK6 ou tetgen qui était en cause. Evidemment la migration VTK 5⇒6 provoque de légers changements dans les maillages générés et c'est bien ça qui met en évidence le problème: avec VTK6, on tombe sur un maillage qui fait buguer la routine de Cédric. Le maillage “nettoyé” l'a été un peu trop et il comporte des trous! Avec pour conséquence derrière que tetgen ne veut pas générer un maillage volumique. Ci dessous une visu paraview du maillage nettoyé où les bords du maillage sont dessinés en rouge:

En regardant de plus près la config du modèle, j'ai vu que la situation du test commité était vraiment une des pires: les trous des vis sont faits pile-poil tangents à des lignes de maillage de la plaque. J'ai donc très légèrement modifié les paramètres de maillage pour que ça passe.

— boman 2017/02/28 07:32