Skip to content

Loss of data concerning physical domain between the gmsh model and the FEniCS mesh object

What's wrong ?

La solution actuellement utilisée pour convertir le maillage généré par gmsh au format .xml, puis pour l'importer dans un script python sous forme d'un objet FEniCS Mesh ne fonctionne pas comme voulu.

Aucun fichier <mesh file name>_physical_region.xml ou <mesh file name>_physical_facet.xml n'est créé lors de la conversation. Les informations sur d'éventuels sous domaines ne peuvent donc pas être importées dans le code FEniCS.

Ce problème a été rencontré lors de l'écriture de la fonction destinée à permettre le passage d'une instance de Gmsh2DRVE à une instance de FEniCS2DRVE. Les commandes actuellement utilisées pour effectuer cette conversion et cet import sont :

    def gmsh_2_Fenics_2DRVE(gmsh_2D_RVE, material_dict):
        os.system(f'dolfin-convert {gmsh_2D_RVE.mesh_abs_path} {gmsh_2D_RVE.name}.xml')
        mesh = fe.Mesh(f'{gmsh_2D_RVE.name}.xml')
        generating_vectors = gmsh_2D_RVE.gen_vect
        subdomains = fe.MeshFunction(<A compléter>)

Lorsque le problème a été détecté, les paramètres primordiaux de gmsh étaient les suivants :

  • export au format .msh version 2
  • option Mesh.SaveAll = 1
  • encodage ASCII du fichier .msh

Pourquoi est-ce qu'il est important de récupérer les données relatives aux physical entities ?

  • Pour les calculs d'homogénéisation, on envisage d'utiliser le système de physical entity de gmsh pour identifier dans le maillage du RVE les deux sous domaines, dans le cas où un matériau mou occupe l'espace complémentaire à la microstructure principale.
  • Par ailleurs, l’identification par physical entity est aussi la solution que l'on a retenue pour exercer une densité surfacique d'efforts extérieurs sur seulement une partie du domaine matériel dans le cadre d'un calcul complet.

D'où cela peut provenir ?

  • Paramètres de gmsh :
    • Mesh.SaveAll ;
    • Mesh.MshFileVersion
  • Outil de conversion utilisé
    • dolfin-convert actuellement;
    • meshio ? (à tester)
  • Problème dans le maillage d'origine

Pistes de résolution envisagées

  • Utiliser meshio à la place de dolfin-convert
  • Fermer à la main les balises manquantes dans le fichier <mesh file name>.xml
  • Recherche d'un jeu de paramètres de gmsh convenable (option SaveAll, version du fichier .msh)
  • Utilisation d'un format de stockage du maillage différent de msh, compatible à la fois avec gmsh et dolfin-convert

Étude et résoution

Dans un premier temps, différentes valeurs de paramètres Mesh.SaveAll, Mesh.Binary et Mesh.MshFileVersion ont été testées. Pour ce test, on choisit d'étudier un RVE composé d'une unique cellule de type auxetic square. Une fois le fichier .msh généré à partir de l'API de gmsh, on test d'effectuer les opérations suivantes, l'objectif étant de détecter le succés ou l'échec de chaque opération.

  • Ouverture du fichier .msh : run(f"gmsh {rve.name}.msh &", shell=True, check=True);
  • Conversion au format DOLFIN xml : run(f'dolfin-convert {rve.mesh_abs_path} {rve.name}.xml', shell=True, check=True);
  • Détection d'un éventuel fichier <mesh file name>_physical_region.xml : f = open(f"{rve.name}_physical_region.xml","r")

On privilégie la commande subprocess.run à os.system. Cela permet de récupérer, dans python, la trace d'éventuelles erreurs d'éxécution de programmes lancés depuis python.

Des fichiers .msh incorrects

Lors d'une discussion avec Jérémy Bleyer, un problème dans les maillages au format .msh a été détecté. Certains éléments 1D apparaissent en double lors de la visualisation du fichier .msh dans gmsh.

Par ailleurs, le type d'erreurs renvoyées par dolfin-convert et l'abscence de fichier <mesh file name>_physical_facet.xml dans les cas où un fichier <mesh file name>_physical_region.xml est généré laisse penser que le problème provient de la défition des éléments 1D dans le .msh.

line 494, in gmsh2xml
index = nodes_as_facets[tuple(nodes)]
KeyError: (5, 66)

-- Erreur de la commande dolfin-convert test_jeremy.msh test_jeremy.xml

Poursuite de la résolution

  • Essayer avec un maillage très simple (carré, peu d'éléments), créé sans opérations booléennes
  • Essayer avec un maillage sans physical entity contenant des entités 1D
  • Le problème des entités 1D ayant une extrémité sur le bord qui apparaissent en double a déjà été rencontré. Regarder s'il a été résolu, et si oui comment.