Malgré des données identiques en entrée, le mailleur Gen4 ne génère pas toujours le même maillage. C'est un problème connu et ça nous pose pas mal de problèmes lorsqu'on veut par exemple recharger des résultats après un calcul. Ce problème est amplifié quand on utilise les capacités parallèles de Gen4 (TBB) ou qu'on change de machine de travail (calculs effectués sur station et résultats visualisés sur un pc de travail).

Pour pouvoir relire d'anciens résultats, il est capital que le maillage utilisé lors de la relecture du fichier de données soit identique à celui qui a été utilisé pour le calcul. Philippe avait fait une tentative de sauvegarde de maillage sur disque qui a été récemment réécrite par Pierre: le maillage est sauvegardé sur disque lors de la génération initiale du maillage et le fichier est relu plus tard si on en a besoin pour le post-processing.

A ce stade, un nouveau problème survient quand on veut changer le maillage d'un test qui a déjà tourné avec d'autres paramètres. Par exemple, imaginons qu'on veuille spécifier une nouvelle densité de mailles en un point de la géométrie pour raffiner le maillage. Malheureusement, la procédure actuelle va charger le maillage précédent, puisque un fichier “maillage” existe dans le workspace. Les nouveaux paramètres ne sont donc pas pris en compte. Seule solution aujourd'hui: il faut supprimer le fichier maillage “à la main” avant de relancer le calcul.

Pour éviter cette gymnastique, qui va très certainement poser problème lorsqu'on va mettre le mailleur dans les mains des étudiants (ou même pour nous, quand on aura oublié cette subtilité), j'ai mis au point un nouveau système qui est censé régénérer le maillage uniquement si les données fournies par l'utilisateur ont changé par rapport à celles qui ont été utilisées pour générer initialement le fichier présent sur disque.

La première idée que j'ai eu pour atteindre à ce but, mais abandonnée aujourd'hui, était de détecter les changements dans le jeu de données grâce aux dates de modification des modules pythons qui le composent. C'est pas simple à faire, puisqu'un module peut en appeler un autre, et ainsi de suite, récursivement. De plus, les problèmes de cette approche sont multiples:

• le maillage est régénéré, même si on fait une modification mineure dans le jeu de données qui n'a aucun impact sur le maillage.
• si on change de machine, il est capital de transférer correctement les fichiers du jeu de données en conservant leur date de modification (soit en activant une option de filezilla, soit en faisant un tar/zip avant transfert)
• si on “update” Metafor, certains fichiers dont dépend le cas test risquent d'être vus comme modifiés, forçant une régénération de maillage (et la perte de l'ancien maillage!).

Bref, cette approche est un peu merdique. La nouvelle approche est la suivante:

Gen4 est maintenant capable de générer des “sommes de contrôle” des données (voir MD5) qui ont été utilisées pour générer initialement un maillage. Ces sommes sont écrites sur disque dans un fichier séparé, à côté du fichier maillage correspondant. Par exemple, si on maille la face #1, on aura le fichier Side1.gen4 dans le workspace accompagné de Side1.gen4.md5 qui contiendra 3 sommes de contrôle MD5: celle de la géométrie d'entrée, celle du maillage d'entrée (certaines courbes peuvent avoir été maillées avec Metafor ou résulter d'un maillage Gen4 d'une face adjacente) et cette du background mesh (position des noeuds et densité). Si une de ces sommes change lors d'une relecture du jeu de données, Gen4 considère que les données d'entrée ont changé et il remplace alors Side1.gen4 après avoir régénéré un nouveau maillage correspondant aux nouveaux paramètres.

Même si cette approche n'est pas infaillible et qu'elle devra certainement être adaptée, je crois qu'on est sur la bonne voie pour rendre le mailleur Gen4 robuste, multi-plateforme et simple d'utilisation.

Pourquoi n'est ce pas infaillible?

• Parce que la somme de contrôle pourrait être identique pour 2 sets de données différents (c'est infiniment peu probable… mais on ne sait jamais)
• Parce que, les données sur lesquelles sont basés cette somme contiennent des nombres flottants qui pourraient ne pas être tout à fait identiques d'un run à l'autre, ou d'une machine à l'autre. Actuellement, je contourne ce problème en réduisant la précision de ces nombres à X décimales; mais je crois qu'il faut faire quelque chose de plus subtil à terme. Par exemple, les nombres 1.234567e-18 et 3.765455e-19 semblent très différents écrits comme ça, mais ils représentent tous les deux “zéro”. Par contre, ces deux nombres, produisent des sommes de contrôle très différentes.

Il faudra donc certainement adapter ce qui est fait (ça ne concerne que le calcul du checksum de la classe gen4::Node). Néanmoins, la structure de calcul et de test du système de rechargement conditionnel de maillage basé sur des sommes de contrôle est en place.

J'essaye actuellement de faire repasser des tests de Vinciane relatifs à des coudes de chien qui cassent suite à un choc. C'est plus compliqué que prévu parce que tout n'a pas été commité à l'époque.

Je profite de ce commit pour ajouter:

• MohrCoulombRuptureCriterion : le critère de rupture de Mohr-Coulomb utilisé par ce problème (il n'est pas encore testé dans la batterie).
• Une mise à jour de tetgen.py qui contient une classe LoadMesh qui n'a rien à faire là et qui est un bel exemple de ce qui ne faut pas écrire comme code. J'ai passé pas mal de temps à nettoyer la classe avant de la commiter.

• J'ai converti les TABs en espaces pour les fichiers *.h, *.cpp et *.inl. Vérifiez vos éditeurs
• J'ai supprimé les espaces en fin de ligne dans ces mêmes fichiers.

— Romain BOMAN 2015/04/28 09:11