Créer et lire dans un maillage des éléments de type polygones quelconques

Créer et lire dans un maillage des éléments de type polyèdres quelconques

Créer et lire un maillage avec gestion des profils sur les entités

Créer et lire un maillage évolutif

Créer et lire une équivalence entre les entités d'un maillage

Créer et lire un maillage avec des éléments de structure

Ecriture et lecture en parallèle par la décomposition de domaine

# Créer et lire dans un maillage des éléments de type polygones quelconques

En plus des types géométriques prédéfinis (exemples : MED_SEG2, MED_SEG3, MED_TRIA3, ...), il est possible de définir dans un maillage non structuré des éléments qui correspondent à des polygones (mailles ou faces) quelconques.

Pour décrire la géométrie et la connectivité des mailles/faces polygones quelconques, il s'agit d'adopter la convention suivante. L'ordre de stockage des polygones est libre -i.e. n'est pas régi par l'ordre des types géométriques (donné par le nombre de sommets). Par exemple, si on a 2 polygones à 5 sommets (P5) et 1 polygone à 6 sommets (P6), on peut stocker la connectivité de ces éléments dans l'ordre suivant : P5, P6, P5. On accède à la connectivité de chaque polygone par l'intermédiaire d'un tableau d'indexation. Pour notre exemple cela revient à avoir les 2 tableaux suivants (les indexations dans MED débutent par convention à l'indice 1) :

En connectivité nodale, les entiers stockés dans le tableau de connectivité correspondent à des numéros de noeuds alors qu'en connectivité descendante, ils correspondent à des numéros d'arêtes.

## Exemple de polygone en connectivité nodale

Voici l'exemple de deux polygones. Les deux polygones sont deux hexagones symétriques. Ils partagent une arête commune la [4,7] qui doit être décrite pour chaque polygone. \image html UsesCase_MEDmesh_13_doc.png Le tableau \a index des polygones est donc le suivant :

index
P1 | P2
--- | ---
1 | 7 | 13

Le tableau \a connectivity contient l'ensemble des noeuds utilisés par les arêtes des polygones

connectivity
P1 | P2
--- | ---
1 | 4 | 7 | 9 | 6 | 3 | 2 | 5 | 8 | 10 | 7 | 4

## Exemple d'utilisation de l'API MED pour l'écriture de polygones

L'écriture de la connectivité des polygones d'un maillage s'appuie sur une routine dédiée \ref MEDmeshPolygonWr / \ref mmhpgw qui prend en paramètres les tableaux d'indexation et de connectivité. A noter que le seul mode de stockage possible du tableau de connectivité est le mode non entrelacé.

Une fois le maillage non structuré crée, ici en dimension 2 : \dontinclude UsesCase_MEDmesh_13.c \skipline MEDmeshCr \until 0) \ref c/UsesCase_MEDmesh_13.c "Fichier d'exemple associé" la définition des noeuds s'effectue classiquement : \dontinclude UsesCase_MEDmesh_13.c \skipline MEDmeshNodeCoordinateWr \until 0) \ref c/UsesCase_MEDmesh_13.c "Fichier d'exemple associé" vient ensuite l'écriture des polygones par les tableaux \a index et \a connectivity : \dontinclude UsesCase_MEDmesh_13.c \skipline MEDmeshPolygonWr \until 0) \ref c/UsesCase_MEDmesh_13.c "Fichier d'exemple associé"

## Exemple d'utilisation de l'API MED pour la lecture de polygones

La lecture de la connectivité des polygones d'un maillage s'effectue tout d'abord par deux appels à la fonction \ref MEDmeshnEntity / \ref mmhnme.

Le premier appel concernant les polygones permet de récupérer la taille du tableau d'indexation (le nombre de polygone présent dans le maillage est égal à la taille de ce tableau -1). \dontinclude UsesCase_MEDmesh_14.c \skipline indexsize = MEDmeshnEntity \until 0) \skipline npoly \ref c/UsesCase_MEDmesh_14.c "Fichier d'exemple associé" Le second appel permet de lire la taille du tableau de connectivité pour lui allouer la mémoire necessaire. \dontinclude UsesCase_MEDmesh_14.c \skipline connectivitysize = MEDmeshnEntity \until 0) \ref c/UsesCase_MEDmesh_14.c "Fichier d'exemple associé" Enfin la routine \ref MEDmeshPolygonRd / \ref mmhpgr va lire les tableaux d'indexation et de connectivité. \dontinclude UsesCase_MEDmesh_14.c \skipline *indexsize \until 0) \ref c/UsesCase_MEDmesh_14.c "Fichier d'exemple associé"

# Créer et lire dans un maillage des éléments de type polyèdres quelconques

## Polyèdres en connectivité nodale

En plus des types géométriques prédéfinis (exemples : MED_SEG2, MED_SEG3, MED_TRIA3, ...), il est possible de définir dans un maillage non structuré des éléments qui correspondent à des (mailles) polyèdres quelconques.

Pour décrire la géométrie et la connectivité des mailles polyèdres quelconques, il s'agit d'adopter la convention suivante. Pour la connectivité nodale, on accède à la connectivité via un système de double indexation : \li un premier tableau d'indexation \a faceindex renvoie à la liste des faces de chaque polyèdre \li un second tableau \a nodeindex renvoie pour chaque face à la liste des noeuds qui la compose Voici un schéma explicitant l'utilisation des trois tableaux dans la connectivité nodale de \b n polyèdres :

A noter que les faces communes sont décrites 2 fois (mêmes listes de noeuds mais orientations différentes) et la normale des faces doit être extérieure.

## Exemple de polyèdres en connectivité nodale

Voici l'exemple d'une boîte constituée de 2 polyèdres. Le premier polyèdre (en bas à gauche) est constitué de 6 faces, le second (en haut à droite) de 7. \image html UsesCase_MEDmesh_15_doc.png Le tableau \a faceindex des polyèdres est donc le suivant :

faceindex
P1 | P2
--- | ---
1 | 7 | 14

Le tableau \a nodeindex permet de trouver les noeuds de chaque face dans le tableau \a connectivity

nodeindex
F1.1 | F1.2 | F1.3 | F1.4 | F1.5 | F1.6 | F2.1 | F2.2 | F2.3 | F2.4 | F2.5 | F2.6 | F2.7
--- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---
1 | 6 | 12 | 17 | 20 | 23 | 27 | 33 | 36 | 42 | 47 | 53 | 56 | 59

Le tableau \a connectivity contient l'ensemble des noeuds utilisés par les faces des polyèdres

connectivity
P1.1 | P1.2 | P1.3 | P1.4 | P1.5 | P1.6 | P2.1 | P2.2 | P2.3 | P2.4 | P2.5 | P2.6 | P2.7
--- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---
1 | 2 | 9 | 3 | 10 | 1 | 12 | 5 | 6 | 11 | 2 | 2 | 11 | 6 | 3 | 9 | 3 | 6 | 5 | 3 | 5 | 10 | 1 | 10 | 5 | 12 | 3 | 13 | 7 | 8 | 15 | 4 | 3 | 4 | 10 | 4 | 15 | 8 | 16 | 5 | 10 | 3 | 6 | 14 | 7 | 13 | 5 | 16 | 8 | 7 | 14 | 6 | 3 | 10 | 5 | 3 | 5 | 6

## Exemple d'utilisation de l'API MED pour l'écriture de polyèdres en connectivité nodale

L'écriture de la connectivité des polyèdres d'un maillage s'appuie sur une routine dédiée \ref MEDmeshPolyhedronWr / \ref mmhphw qui prend en paramètres les tableaux d'indexation et de connectivité. A noter que le seul mode de stockage possible du tableau de connectivité est le mode non entrelacé.

L'exemple suivant propose l'écriture de la connectivité de mailles polyèdres en connectivité nodale.

Après la création classique d'un maillage non structuré : \dontinclude UsesCase_MEDmesh_15.c \skipline MEDmeshCr \until { \ref c/UsesCase_MEDmesh_15.c "Fichier d'exemple associé" Les noeuds utilisés par les polyèdres sont crées : \dontinclude UsesCase_MEDmesh_15.c \skipline MEDmeshNodeCoordinateWr \until { \ref c/UsesCase_MEDmesh_15.c "Fichier d'exemple associé" Enfin, la connectivité des polyèdres est enregistrée : \dontinclude UsesCase_MEDmesh_15.c \skipline MEDmeshPolyhedronWr \until { \ref c/UsesCase_MEDmesh_15.c "Fichier d'exemple associé"

A noter qu'au même titre que les autres entités d'un maillage, les polyèdres (tout comme les polygones) portent un numéro de famille (0 par défaut) et peuvent porter un nom ou un numéro optionnel.

## Exemple d'utilisation de l'API MED pour la lecture de polyèdres en connectivité nodale

La lecture de la connectivité des polyèdres d'un maillage demande une approche spécifique. Il est d'abord nécessaire d'appeler plusieurs fois la routine \ref MEDmeshnEntity / \ref mmhnme afin de récupérer la taille des tableaux d'indexation. Après la lecture du nombre total de noeuds présent dans le maillage \dontinclude UsesCase_MEDmesh_16.c \skipline nnodes = MED \until 0) \ref c/UsesCase_MEDmesh_16.c "Fichier d'exemple associé" nous lisons le nombre de polyèdres ( égal à la taille du tableau #MED_INDEX_FACE -1 ) \dontinclude UsesCase_MEDmesh_16.c \skipline faceindexsize = MED \until 0) \skipline npoly \ref c/UsesCase_MEDmesh_16.c "Fichier d'exemple associé" et la taille du tableau d'indexes des noeuds #MED_INDEX_NODE \dontinclude UsesCase_MEDmesh_16.c \skipline nodeindexsize = MED \until 0) \ref c/UsesCase_MEDmesh_16.c "Fichier d'exemple associé" nous lisons enfin la taille du tableau \a connectivity contentant les numéros des noeuds utilisés par les faces des polyèdres \dontinclude UsesCase_MEDmesh_16.c \skipline connectivitysize = MED \until 0) \ref c/UsesCase_MEDmesh_16.c "Fichier d'exemple associé" La routine \ref MEDmeshPolyhedronRd / \ref mmhphr va permettre de lire les tableaux d'indexation et de connectivité \dontinclude UsesCase_MEDmesh_16.c \skip MEDmeshNodeCoordinateRd \skipline malloc \until 0) \ref c/UsesCase_MEDmesh_16.c "Fichier d'exemple associé"

## Polyèdres en connectivité descendante

Pour la connectivité descendante, un seul niveau d'indexation suffit (faceindex). \li Le tableau \a connectivity contient les numéros des faces. \li Le tableau \a nodeindex contient alors le type géométrique de chaque face (exemple : MED_TRIA3). A noter que dans ce cas, nodeIndexSize == connectivitySize .

Voici un schéma explicitant l'utilisation des trois tableaux dans la connectivité descendante de \b n polyèdres :

# Créer et lire un maillage avec gestion des profils sur les entités

Un profil sur les entités d'un maillage permet l'écriture ou la lecture sur un sous-ensemble de ces entités. Un profil est un objet stocké dans un fichier MED. Un profil est un tableau de numéros d'entités (numérotation MED relative à un type géométrique d'élément commençant à 1) associés aux valeurs à traiter. La définition d'un profil se fait selon les conventions suivantes : les numéros d'entité utilisés pour définir un profil sont ceux de la numérotation implicite (ordre d'apparition des entités par ordre croissant). Un profil est une liste compacte : on ne met que les numéros représentatifs. Exemple : sur un maillage de 30 noeuds, si on a un champ portant sur les noeuds de numéros de référence 4, 5 et 12, le profil correspondant sera la liste (4,5,12).

La routine \ref MEDprofileWr / \ref mpfprw permet d'écrire un profil dans un fichier MED. Un profil est identifié par son nom (chaîne de taille \ref MED_NAME_SIZE caractères).

A la lecture, la routine \ref MEDnProfile / \ref mpfnpf va lire le nombre de profil dans un fichier. Il s'agit ensuite d'itérer sur chaque profil afin de récupérer pour chacun d'eux : le nom et la taille du tableau du profil avec la routine \ref MEDprofileInfo / \ref mpfpfi, le tableau des numéros d'entités avec \ref MEDprofileRd / \ref mpfprr.

Lorsqu'on connaît le nom du profil, la routine permet \ref MEDprofileSizeByName / \ref mpfpsn de lire la taille du tableau.

Au niveau de l'API sur les maillages, l'utilisation des profils est possible en écriture ou en lecture des coordonées des noeuds et de la connectivité des éléments d'un maillage non structuré avec les routines : \ref MEDmeshNodeCoordinateWithProfileWr / \ref mmhcow pour l'écriture des coordonnées, \ref MEDmeshNodeCoordinateWithProfileRd / \ref mmhcor pour la lecture des coordonnées, \ref MEDmeshElementConnectivityWithProfileWr / \ref mmhypw pour l'écriture des connectivités, \ref MEDmeshElementConnectivityWithProfileRd / \ref mmhypr pour la lecture des connectivités. A noter également la routine \ref MEDmeshnEntityWithProfile / \ref mmhnep qui peut récupérer le nombre d'entité à lire selon un profil donné.

Pour toutes ces routines, il est possible de spécifier le mode de stockage des tableaux de coordonnées ou de connectivité en mémoire. Deux modes sont possibles : le mode \ref MED_GLOBAL_STMODE indique que le stockage utilisé contient en mémoire toutes les valeurs relatives à toutes les entités d'un même type ; le mode \ref MED_COMPACT_STMODE indique que le stockage utilisé est compact et ne contient en mémoire que le sous-ensemble de valeurs relatives au profil.

# Créer et lire un maillage évolutif

Dans MED, un maillage peut évoluer par étape, chaque étape étant estampillée par un couple <pas de temps, numéro d'ordre> à l'instar des étapes de calcul d'un champ de résultat.

Une évolution peut porter un maillage déformable à topologie constante (les coordonnées des noeuds ou d'un sous-ensemble des noeuds sont modifiées à chaque étape), un maillage à déformation solide (selon une matrice de transformation pour chaque étape applicable aux coordonnées des noeuds), un maillage redéfinissable (les connectivités des mailles changent au cours des étapes).

A la création d'une étape de calcul, les informations de l'étape précédente inchangées sont automatiquement reportées : coordonnées, connectivités, numéros optionnels, noms optionnels, numéros de famille. Il est donc possible de créer une étape d'évolution sans avoir à y reporter toutes ces données. L'utilisateur a la responsabilité de maintenir la cohérence des informations covariantes au cours des différentes étapes.

A noter qu'un champ de résultat repose désormais sur une étape d'évolution existante d'un maillage (par défaut l'étape initiale <MED_NO_DT, MED_NO_IT>). Il est nécessaire de stocker le maillage initial <MED_NO_DT, MED_NO_IT> avant toute évolution.

Au cours des évolutions d'un maillage, les types géométriques d'éléments doivent rester identiques. Si de nouveaux types géométriques apparaissent, il faut créer un nouveau maillage.

Pour ce qui concerne l'écriture des maillages déformables à topologie constante, il faut utiliser la routine \ref MEDmeshNodeCoordinateWithProfileWr / \ref mmhcow en passant en paramètre le pas de temps et ou le numéro d'ordre correspondant à l'étape, le profil sélectionnant les noeuds dont les coordonnées sont modifiées, le tableau des nouvelles coordonnées.

Le cas d'utilisation suivant après création du maillage initial, créée 2 évolutions successives de sous-ensembles des coordonnées des noeuds du maillage.

\include UsesCase_MEDmesh_6.c

A la lecture des maillages déformables à topologie constante, une fois la lecture du maillage initiale effectuée, il faut itérer sur les différentes étapes d'évolution présentes dans le maillage (le nombre d'étape est lue par les routines \ref MEDmeshInfoByName / \ref mmhmin ou \ref MEDmeshInfo / \ref mmhmii) et à chaque étape : récupérer les valeurs du pas de temps et du numéro d'itération avec la routine \ref MEDmeshComputationStepInfo / \ref mmhcsi ; déterminer la nature du changement parmi les cas possibles pré-cités avec la routine \ref MEDmeshnEntityWithProfile / \ref mmhnep et également récupérer le nombre de noeuds à lire selon le mode de stockage mémoire passé en paramètre ; lire les nouvelles coordonnées des noeuds avec la routine \ref MEDmeshNodeCoordinateWithProfileRd / \ref mmhcor.

C'est ce que fait le cas d'utilisation suivant.

\include UsesCase_MEDmesh_7.c

Le cas d'utilisation suivant propose une approche plus générique dans la lecture des maillages déformables à topologie constante.

\include UsesCase_MEDmesh_8.c

Pour ce qui concerne l'écriture des maillages avec déformation solide, il faut utiliser la routine \ref MEDmeshNodeCoordinateTrsfWr / \ref mmhtfw en passant en paramètre le pas de temps et ou le numéro d'ordre correspondant à l'étape et la matrice de transformation. Cette matrice comporte 7 valeurs réelles : les trois premières définissent la translation à appliquer selon l'ordre des axes définis pour le maillage et les quatres suivantes définissent une rotation phi par le quarternion (p4,p5-7) où p4 est le scalaire et p5-7 le vecteur décrit suivant l'ordre des axes définis pour le maillage. S'il y a moins de trois axes définis, les paramètres inutiles à la transformation doivent être à zéro.

\include UsesCase_MEDmesh_9.c

A la lecture des maillages avec déformation solide, une fois la lecture du maillage initiale effectuée, il faut itérer sur les différentes étapes d'évolution présentes dans le maillage (le nombre d'étape est lue par les routines \ref MEDmeshInfoByName / \ref mmhmin ou \ref MEDmeshInfo / \ref mmhmii) et à chaque étape : récupérer les valeurs du pas de temps et du numéro d'itération avec la routine \ref MEDmeshComputationStepInfo / \ref mmhcsi ; déterminer la nature du changement parmi les cas possibles pré-cités avec la routine \ref MEDmeshnEntityWithProfile / \ref mmhnep et également vérifier la présence de la matrice de transformation ; lire la matrice de transformation avec la routine \ref MEDmeshNodeCoordinateTrsfRd / \ref mmhtfr.

Le cas d'utilisation suivant permet de lire de manière générique un maillage évolutif, à la fois s'il s'agit d'un maillage déformable à topologie constante ou d'un maillage avec déformation solide.

\include UsesCase_MEDmesh_12.c

# Créer et lire une équivalence entre les entités d'un maillage

La notion d'équivalence permet de gérer des listes de correspondances mettant en relation deux à deux des entités de même type (deux noeuds, deux mailles, deux arêtes ou deux faces). Voici quelques exemples :

- Dans le cadre d'une symétrie de révolution, un bord de domaine est associé à un autre bord. Ces bords n'étant pas des volumes, les mailles en correspondances sont dans ce cas des mailles 2D.
- Dans le cadre de voisinages non conformes, on veut mémoriser une liste de mailles 3D liées. La notion d'équivalence est parfaite et concise.

## Création d'une équivalence entre entités d'un même maillage

Une équivalence est identifiée par son nom (chaîne de \ref MED_NAME_SIZE caractères) et possède une description (chaîne d'au plus \ref MED_COMMENT_SIZE). La création d'équivalences est optionnelle. Un fichier peut contenir zéro ou plusieurs équivalences pour chaque maillage local au fichier. La routine \ref MEDequivalenceCr / \ref meqcre permet la création d'équivalences d'entités d'un maillage.

\dontinclude test12.c \skipline MEDequivalenceCr \ref c/test12.c "Fichier d'exemple associé"

## Ecriture des correspondances d'une équivalence entre entités de même type

Une fois l'équivalence créée, il ne reste plus qu'à y associer les correspondances d'entitées par l'intermédiaire d'un tableau de correspondances. Si l'on décrit des correspondances sur des types d'entités différents ou sur différentes étapes d'évolution du maillage, plusieurs tableaux de correspondances peuvent apparaîtres dans une équivalence. Les numéros d'entités en correspondances apparaissent sous forme d'une suite de pairs dans un tableau de correspondances.

Voici un exemple :

correspondence
C1 | C2 | C3
--- | --- | ---
1 | 2 | 3 | 4 | 5 | 6

Le tableau de correspondances appliqué à des entités de type MED_TRIA3 (triangle à 3 noeuds) décrit les 3 correspondances suivantes :

- (triangle numéro 1 , triangle numéro 2), (triangle numéro 3 , triangle numéro 4), (triangle numéro 5 , triangle numéro 6).

Les numéros d'entités utilisés sont ceux de la numérotation implicite des entités même si une numérotation optionnelle est présente (régle invariante dans MED). La routine \ref MEDequivalenceCorrespondenceWr / \ref meqcow permet d'écrire un tableau de correspondances à une étape d'évolution du maillage ( ( #MED_NO_DT , #MED_NO_IT ); par défaut) et pour un type d'entité . Si le type d'entité est un élément, il faut préciser le type géométrique de l'élément.

\dontinclude test12.c \skipline MEDequivalenceCorrespondenceWr \until 0) \ref c/test12.c "Fichier d'exemple associé"

## Lectures des équivalences

La découverte des équivalences définies sur un maillage se fait par itération. Le nombre d'équivalences sur lesquelles itérer est renvoyé par la routine \ref MEDnEquivalence / \ref meqneq.

\dontinclude test13b.c \skipline MEDnEquivalence \ref c/test13b.c "Fichier d'exemple associé"

Chaque appel à \ref MEDequivalenceInfo / \ref meqeqi renvoie ensuite l'ensemble des informations relatives à une équivalence, à savoir :

- Nom de l'équivalence
- Description de l'équivalence
- Nombre d'étapes d'évolution du maillage pour lesquelles au moins un tableau de correspondance existe
- Nombre de correspondances existantes pour l'étape par défaut ( #MED_NO_DT , #MED_NO_IT )

\dontinclude test13b.c \skipline for ( \skipline MEDequivalenceInfo \ref c/test13b.c "Fichier d'exemple associé"

Si le maillage concerné ne possède qu'une étape d'évolution (obligatoirement ( #MED_NO_DT , #MED_NO_IT ) ) ou s'il n'y a qu'une étape d'évolution de maillage pour laquelle l'équivalence est définie et que le nombre de correspondances pour l'étape par défaut ( #MED_NO_DT , #MED_NO_IT ) est non nul, il n'est pas necessaire d'inspecter les différentes étapes par des appels itératifs à \ref MEDequivalenceComputingStepInfo / \ref meqcsi.

## Lectures des équivalences pour différentes étapes d'évolution du maillage

Si l'équivalence est définie sur plusieurs étapes d'évolution de maillage la fonction \ref MEDequivalenceComputingStepInfo / \ref meqcsi permet d'obtenir les informations suivantes pour chaque étape :

- \numdt
- \numit
- \nocstpncorrespondence

\dontinclude test13b.c \skipline _cstpit=1 \skipline MEDequivalenceComputingStepInfo \until ); \ref c/test13b.c "Fichier d'exemple associé"

## Lectures des correspondances d'une équivalence entre entités --de même type-- à une étape d'évolution du maillage

La fonction \ref MEDequivalenceCorrespondenceSize / \ref meqcsz lit le nombre de correspondances d'une étape d'évolution du maillage et permet de dimensionner le tableau de correspondances. Cette fonction peut être appelée pour chaque couple ( type d'entité , type géométrique) présent dans le maillage si l'on n'a pas d'information concernant la présence d'équivalence sur des entités particulières.

\dontinclude test13b.c \skipline MEDequivalenceCorrespondenceSize \skipline if (ncor \skipline malloc \ref c/test13b.c "Fichier d'exemple associé"

Une fois le tableau de correspondances dimensionné, la fonction \ref MEDequivalenceCorrespondenceRd / \ref meqcor permet de lire le tableau de correspondance pour un type d'entité et une étape d'évolution du maillage fixés.

\dontinclude test13b.c \skipline MEDequivalenceCorrespondenceRd \until ); \ref c/test13b.c "Fichier d'exemple associé"

## Liens vers les fichiers exemples utilisés

- \ref c/test12.c "Fichier d'exemple test12.c"

- \ref c/test13.c "Fichier d'exemple test13.c"

- \ref c/test13b.c "Fichier d'exemple test13b.c"

# Créer et lire un maillage avec des éléments de structure

MED permet de créer des modèles d'éléments de structure. Un modèle d'élément est propre à un fichier qui doit être celui de(s) maillage(s) de calcul qui utilisent le modèle. Il peut y avoir plusieurs modèles d'éléments de structures dans un même fichier. Une fois le modèle défini, l'élément de structure devient un nouveau type d'élément d'un maillage de calcul au même titre que les autres types d'éléments pré-définis dans le modèle.

Le modèle MED réserve des noms de modèles pour les particules (\ref MED_PARTICLE_NAME), les billes (\ref MED_BALL_NAME) et les poutres (\ref MED_BEAM_NAME). Cette liste de noms réservés est amenée à s'étoffer au fil des versions de MED, de fait tous les noms de modèle commençant par « MED_ » sont également réservés. A chaque nom de modèle réservé ou fixé par l'utilisateur est associé un numéro de type géométrique unique au fichier. Ce numéro complète les numéros existants pour les types géométriques éléments finis. Le numéro de type d'un élément de structure est utilisable comme celui des types géométriques classiques pour s'informer de la présence du type d'élément dans un maillage de calcul. Le type d'entité de ce type d'élément est \ref MED_STRUCT_ELEMENT.

Un modèle de structure utilisé dans un fichier doit être complètement défini dans ce fichier. Ainsi les maillages et les champs s'appuyant sur des élements de ce modèle pourront être relus par tout code s'intéressant aux éléments de structure. La description d'un modèle d'élément de structure peut s'appuyer sur un maillage support.

Si le modèle ne contient pas de maillage support, chaque élément de structure associé au modèle, s'appuie sur les noeuds du maillage de calcul pour se positionner. C'est le cas par exemple du modèle pré-défini des particules. Les coordonnées de ces noeuds peuvent évoluer au cours du temps selon le principe des maillages évolutifs présentés précédemment.

Un maillage support contient 1 ou plusieurs noeuds et éventuellement des mailles. La connectivité des éléments de structure y est uniquement décrite en mode nodal. Les noeuds d'un maillage support sont définis indépendamment des maillages de calcul. Ces noeuds ne sont pas référencés dans les maillages de calculs. Les coordonnées des noeuds sont définies dans un espace de dimension égale à celle de l'élément de structure. Le repère de coordonnées est propre à la description du modèle de l'élément. Les mailles définies dans un maillage support sont indépendantes des maillages de calcul et ne sont pas référencées dans les maillages de calcul. S'il y a des mailles dans le maillage support, la connectivité des éléments de structure référence des numéros de mailles dans les maillages de calcul. Il ne peut y avoir qu'un seul type géométrique de maille dans un maillage support. Dans un maillage support, il est pas utile d'écrire les numéros de familles (toutes les entités sont rattachées à la famille 0 par défaut), les numéros optionnels, les noms optionnels des entités du maillage. Un maillage support ne peut contenir de polygones ou polyèdres quelconques.

Les caractéristiques d'un élément de structure sont décrites par des attributs. Il existe deux types d'attributs caractéristiques : des attributs caractéristiques à valeur constante pour tous les éléments du modèle (ou attributs caractéristiques du modèle), des attributs caractéristiques à valeur variable selon les éléments du modèle (la valeur est alors définie au niveau des éléments dans les maillage de calcul). Les attributs caractéristiques sont typé par les types MED standards (entier, réel, chaîne de caractères de taille \ref MED_NAME_SIZE). Un attribut peut comporter plusieurs composantes au même titre qu'un champ.

La création d'un modèle d'élément de structure se fait avec la routine \ref MEDstructElementCr / \ref msecre. Un modèle est identifié par son nom qui est une chaîne de \ref MED_NAME_SIZE caractères. La création d'un attribut caractéristique à valeur variable se fait avec la routine \ref MEDstructElementVarAttCr / \ref msevac. La création d'un attribut caractéristique du modèle se fait avec les routines \ref MEDstructElementConstAttWr / \ref mseraw, \ref mseiaw, \ref msesaw. La routine \ref MEDmeshStructElementVarAttWr / \ref mmhraw, \ref mmhiaw, \ref mmhsaw permet d'écrire les valeurs d'un attribut à valeur variable, l'appel à cette routine se faisant au moment de la création d'un maillage de calcul. Les routines \ref MEDstructElementConstAttWr / \ref mseraw, \ref mseiaw, \ref msesaw et \ref MEDstructElementConstAttWithProfileWr / \ref mserpw, \ref mseipw, \ref msespw permettent d'écrire les valeurs d'un attribut constant respectivement sans et avec un profil.

La création d'un maillage support se fait avec une routine spécifique \ref MEDsupportMeshCr / \ref msmcre. L'écriture des coordonnées des noeuds et de la connectivité des mailles se fait avec les mêmes routines que celles utilisées pour les maillages de calcul. Un maillage support est identifié par son nom qui est une chaîne de \ref MED_NAME_SIZE caractères.

Le cas d'utilisation suivant définit 3 modèles d'éléments de structure différents pour les particules, les billes et les poutres. Les deux derniers modèles s'appuient sur des maillages support également définis dans le fichier. Des éléments de structure qui correspondent à ces modèles sont finalement utilisés dans un maillage de calcul.

\include UsesCase_MEDstructElement_1.c

La routine \ref MEDstructElementInfoByName / \ref msesin permet de récupérer les informations relatives à un modèle d'élément de structure dont on connaît le nom. Un autre mode d'accès en lecture consiste à utiliser la routine \ref MEDnStructElement / \ref msense pour lire le nombre de modèle dans un fichier. Il s'agit ensuite d'itérer sur ces modèles. La routine \ref MEDstructElementInfo / \ref msesei permet de lire à chaque itération les informations relatives à un modèle d'élément de structure. Pour ce qui concerne la lecture des attributs constants, la routine \ref MEDstructElementConstAttInfo / \ref msecai permet de lire les informations relatives à ce type d'attribut et les routines \ref MEDstructElementConstAttRd / \ref mserar, \ref mseiar, \ref msesar permettent de lire les valeurs d'un attribut constant sans et avec un profil. Pour ce qui concerne les attributs variables, la routine \ref MEDstructElementVarAttInfo / \ref msevai permet de lire les informations relatives à ce type d'attribut et les routines \ref MEDmeshStructElementVarAttRd / \ref mmhrar, \ref mmhiar, \ref mmhsar permettent de lire les valeurs d'un attribut variable.

A noter également l'existence : de la routine \ref MEDstructElementName / \ref msesen qui à partir du numéro de type géométrique de l'élément de structure, fournit le nom de cet élément ; de la routine \ref MEDstructElementGeotype / \ref msesgt qui à partir du nom de l'élément renvoie son type. Enfin la routine \ref MEDstructElementAttSizeof / \ref mseasz renvoie la taille en octets du type élémentaire d'un attribut constant ou variable, ce qui permet d'allouer correctement la taille des tableaux pour lire les valeurs des attributs.

La routine \ref MEDsupportMeshInfoByName / \ref msmsni permet de récupérer les informations relatives à un maillage support dont on connaît le nom. Un autre mode d'accès en lecture consiste à utiliser la routine \ref MEDnSupportMesh / \ref msmnsm afin de lire le nombre de maillage support dans un fichier. Il s'agit ensuite d'itérer sur ces maillages support et à chaque itération de lire les informations relative au maillage avec la routine \ref MEDsupportMeshInfo / \ref msmsmi. La lecture des coordonnées des noeuds et de la connectivité des mailles se fait avec les mêmes routines que celles utilisées pour les maillages de calcul.

Ce cas d'utilisation montre comment à partir d'un maillage de calcul, accéder aux modèles d'éléments de structure et aux maillages supports.

\include UsesCase_MEDstructElement_3.c

# Ecriture et lecture en parallèle par la décomposition de domaine

En vue de calculs parallèles, le domaine de calcul est subdivisé en sous-domaines où se répartissent les maillages. Classiquement, chaque sous-domaine sera traité par un seul processeur qui aura uniquement accès aux données des autres sous-domaines par l'intermédiaire de messages.

Du point de vue du stockage, un maillage distribué a la même structure qu'un maillage MED classique mais ses composantes (entités géométrique, familles, groupes) peuvent être réparties sur plusieurs sous-domaines affectés à des processeurs disjoints. Lors de cette distribution certains sommets, faces, arêtes ou mailles se retrouvent sur la frontière commune de deux sous-domaines. L'ensemble de ces éléments communs à deux sous-domaines constitue un joint. Dans un cadre très général, les éléments communs à deux sous-domaines peuvent apparaître comme : la jointure de deux maillages qui se correspondent parfaitement (on parle alors de raccordement conforme), la jointure de deux maillages de pavage différent (raccordement non conforme), le recouvrement de deux maillages qu'il soit conforme ou non.

La notion de joint est assez générale pour permettre de stocker ces trois types d'interface. Elle consiste à donner la liste des couples des numéros correspondant des entités en regard vues du domaine local et vues du domaine distant.

Un maillage distribué est donc entièrement déterminé par la donnée des maillages affectés à chacun des sous-domaines, par la définition de « joints » - raccord entre les maillages de sous-domaines voisins, par une numérotation globale optionnelle des entités.

Comme les maillages sont distribués, les données MED s'y rattachant peuvent être stockées dans plusieurs fichiers. La liste de ces fichiers est rassemblée dans un fichier maître au format ASCII. Ce fichier permet de repérer où se trouvent stockées les parties de maillages distribuées correspondant à chaque sous-domaine. Il contient : un entête d'identification ; le nombre de sous-domaines sur lesquels sont distribués les maillages ; les informations nécessaires pour repérer les parties de maillages affectées à chaque sous-domaine. Pour ce faire, il y a autant de lignes que de parties de maillages distribués. Chaque ligne se compose : du nom de maillage global, du numéro de sous-domaine concerné, du nom de maillage local correspondant au maillage global sur ce sous-domaine, du nom de la machine hébergeant le fichier MED contenant ces informations (ce nom peut éventuellement être une adresse IP de la machine et ne comportera pas de blanc), du chemin absolu ou relatif menant à ce fichier

Le fichier ASCII sera au format unix, et le retour à la ligne est un caractère ASCII 10 (caractère Carriage Return seul sans caractère Line Feed comme sous windows). Dans les chemins, les sous répertoires seront délimités par le caractère '/'. Toute ligne commençant par '#' sera ignorée par la librairie (commentaires). Mais un '#' en cours de ligne ne sera pas interprété comme un commentaire.
Les fichiers MED correspondant à chaque sous-domaine sont repérés par leur chemin absolu ou relatif dans le système de fichier. Dans le cas relatif, l'accès aux fichiers depuis la librairie pourra dépendre de la machine ou du système d'exploitation sur lequel on s'exécute. A charge de l'utilisateur de vérifier l'interprétation cohérente des chemins de fichiers relatifs.

Voici un exemple de fichier maître, décrivant la répartition de 2 maillages VIT et TEMP sur 4 sous domaines disjoints. Le calcul s'effectue sur un solide (où seule est définie la température) baignée d'un liquide (ou sont définies les vitesses et températures)

    # MED Fichier v3.0
    #
    # Nombre de sous-domaines
    4
    #
    # fichiers MED par sous-domaine
    VIT 1 VIT_1 localhost /absolute/path/fichier_dom_1
    VIT 2 VIT_2 localhost /absolute/path/fichier_dom_2
    TEMP 1 TEMP_1 localhost /absolute/path/fichier_dom_1
    TEMP 2 TEMP_2 localhost /absolute/path/fichier_dom_2
    TEMP 3 TEMP_3 localhost /absolute/path/fichier_dom_3
    TEMP 4 TEMP_4 localhost /absolute/path/fichier_dom_4

La création ou la transformation du fichier maître est à la charge du découpeur. On suppose que ce fichier est cohérent dans l'utilisation de la librairie.

A l'écriture, les routines disponibles permettent de : créer un joint dans un maillage (\ref MEDsubdomainJointCr / \ref msdjcr) ; écrire un tableau de correspondances entre binômes d'entités du maillage dans un joint (\ref MEDsubdomainCorrespondenceWr / \ref msdcrw) ; écrire la numérotation globale associée à un type d'entité pour la repérer sur le domaine global (\ref MEDmeshGlobalNumberWr / \ref mmhgnw).

A la lecture, les routines disponibles permettent de : lire le nombre de joints dans un maillage (\ref MEDnSubdomainJoint / \ref msdnjn) ; lire les informations concernant un joint (\ref MEDsubdomainJointInfo / \ref msdjni), lire le nombre de couple en correspondance d'un type donné dans un joint (\ref MEDsubdomainComputingStepInfo / \ref msdcsi) ; lire le nombre d'entités en correspondance dans un joint pour un couple d'entités et une séquence de calcul donnés (\ref MEDsubdomainCorrespondenceSize / \ref msdcsz); lire les informations sur les couples d'entités en correspondance dans un joint pour une séquence de calcul donnée (\ref MEDsubdomainCorrespondenceSizeInfo / \ref msdszi) ; lire un tableau de correspondances entre binômes d'entités du maillage dans un joint (\ref MEDsubdomainCorrespondenceRd / \ref msdcrr) ; lire la numérotation globale associée à un type d'entité pour la repérer sur le domaine global (\ref MEDmeshGlobalNumberRd / \ref mmhgnr).

Les cas d'utilisation suivant illustrent comment écrire et lire des maillages avec des joints et un système de numérotation global.

\include test29.c

\include test30.c

\include test31.c

\include test32.c