2 Guide de l’utilisateur

Ce chapitre décrit l’installation du logiciel CERF, ainsi que son utilisation.

2.1 Installation du logiciel

2.1.1 Prérequis

CERF est un logiciel écrit en Fortran 90 utilisant la bibliothèque MPI pour la communication entre les différents processus.

Important

Il est donc nécessaire d’avoir :
- un système d’exploitation ou émulateur Linux (Ubuntu, CentOS, WSL sous Windows 10 ou 11, Mac OS, ….)
- un compilateur Fortran 90 (gfortran, ifort, …)
- la bibliothèque MPI (OpenMPI)

Les fichiers de sortie de CERF sont au format Tecplot (VTK à venir). Il est donc recommandé d’avoir un logiciel de visualisation tel que ParaView ou Visit.

2.1.2 Installation

Pour installer CERF, après avoir téléchargé l’archive ‘cerf_v1.0.tar’, il suffit de la décompresser dans un répertoire de votre choix.

tar xvf cerf_v1.0.tar .

L’archive déployée présentera alors une arborescence comme illustré sur Figure 2.1.

Le répertoire principal de CERF comporte 4 sous-répertoires : doc, sources, lib et exec.

le répertoire doc contient la documentation du logiciel
le répertoire sources contient les sources du logiciel
le répertoire lib contient les bibliothèques créées à la compilation et nécessaires à la création des exécutables
le répertoire exec contient tous les exécutables du logiciel. C’est le répertoire de travail

Pour installer CERF, il suffit de se rendre dans le répertoire exec et de lancer le Makefile.

cd CERF/exec
make

Note

Par défaut, le Makefile utilise le compilateur gfortran et la bibliothèque OpenMPI. Cependant il est possible de modifier ces paramètres dans le Makefile.

Paramètre FC = “gfortran” ou “ifort” ou ….. pour un calcul séquentiel
Paramètre FC = “mpif90” ou ….. pour un calcul parallèle
Paramètre MPI = “_MPI” ou “NONE_MPI” suivant que la librairie MPI est installée ou non
Paramètre FFLAGS pour redéfinir les paramètres de compilation

Note

Le Makefile est configuré pour ne recompiler que les fichiers sources nouvellement créés ou modifiés. En cas de recompilation complète, par exemple suite à un changement de machine, il est conseillé de nettoyer les fichiers objets et exécutables avant de relancer le Makefile, par la commande:

make clean

À l’issue de l’exécution du Makefile, les exécutables de CERF sont créés dans le répertoire exec : cerf, cerf_amr, cerf_input et cerf2tec.

Note

En fonction du système d’exploitation utilisé, les exécutables peuvent comporter l’extension “.exe” ou non.

2.1.3 Déroulement d’un calcul

Figure 2.2: Déroulement d’un calcul de **CERF**

Comme illustré sur Figure 2.2, le déroulement d’un calcul de CERF se fait en plusieurs étapes. Une phase de pré-traitement permet de générer le maillage, les conditions initiales du calcul et les paramètre du calcul. Cette phase est réalisée par l’exécutable cerf_input. Une fois le maillage généré, le calcul est effectué par l’exécutable cerf et le maillage peut être modifié par l’exécutable cerf_amr. Enfin, l’exécutable cerf2tec permet de convertir les fichiers de sortie en format Tecplot pour une phase de post-traitement.

cerf_input
En entrée, cerf_input lit un fichier de configuration .inp dans un format spécifique à CERF, dans lequel sont définis les paramètres physiques et numériques du modèle à traiter, le maillage, les conditions initiales, les conditions aux limites, … etc … Dans le cas où le maillage est défini par un fichier au format GMSH V2.2 il lira également le fichier .msh. Dans le cas où des pénalisations de fluides rigides sont définies, il lira également les objets dans les fichiers .obj.
En sortie, cerf_input génère un fichier binaire cerfbin_000 contenant la définition du maillage maître et autant de fichiers binaires cerfbin_* que de domaines requis, contenant toutes les informations des domaines : paramètres, maillage, degrés de liberté, conditions aux limites, …. etc …
cerf
En entrée, cerf lit les fichiers binaires cerfbin_* générés par cerf_input ou modifiés par cerf_amr. Puis il effectue un cacul en parallèle (via les processus MPI) sur les domaines définis durant la période de temps requise. Dans cette étape le maillage est fixe. En sortie, à l’issue du calcul, cerf met à jour les fichiers binaires cerfbin_* avec les nouvelles valeurs des champs calculés.
cerf_amr
En entrée, cerf_amr lit les fichiers binaires cerfbin_* générés par cerf. Puis il effectue un raffinement du maillage en fonction de critères définis dans le fichier de configuration .inp. En sortie, cerf_amr met à jour les fichiers binaires cerfbin_* avec le nouveau maillage. Par ailleurs, cerf_amr génère un fichier cerfamr.dat contenant les informations liées au maillage maître : critère de raffinement, niveau de raffinement, …. Dans le cas où des pénalisations de fluides rigides sont définies, cerf_amr génère également les fichiers solide_* contenant la nouvelle position des objets.
cerf2tec
En entrée, cerf2tec lit les fichiers binaires cerfbin_* . Puis il convertit les fichiers binaires en un seul fichier ASCII, nommé cerfout.dat au format Tecplot pour une visualisation des résultats.

Lancer un calcul en utilisant que des lignes de commande peut devenir fastidieux. C’est pourquoi on utilise souvent des scripts. Voici, ci-après, un exemple de script qui permet de lancer un calcul complet de CERF en une seule commande. Il suffit de le modifier en fonction de vos besoins.

Exemple de script shell

Voici un exemple de script shell permettant de lancer un calcul à partir du fichier dam.inp. Ce script lance le calcul sur 4 processeurs puis la modification du maillage 20 fois. Les fichiers de sortie sont renommés en fonction de l’itération afin de pouvoir visualiser l’évolution du calcul.

#!/bin/bash
./cerf_input dam.inp
./cerf2tec
mv cerfout.dat d_0.dat
mv cerfamr.dat d_mame_0.dat
for i in $(seq 1 20 )
do
mpirun -np 4 ./cerf
./cerf2tec
mv cerfout.dat d_$i.dat
./cerf_amr
mv cerfamr.dat d_mame_$i.dat
done

2.2 Le fichier de configuration *.inp

2.2.1 Généralités

Le fichier de configuration est un fichier texte permettant de définir tous les paramètres et entités nécessaires à la simulation. Il est divisé en plusieurs sections, chacune débutant par une entête de 4 caractères. Les entêtes, à renseigner dans cet ordre, sont les suivants : PHYS, MAME, BATH, INIT, COND, MESH, OBST, NUME. Chaque entête est suivi sur la même ligne de 1 ou 2 entiers qui définissent le code et éventuellement l’argument. Toutes les lignes commençant par un “!” sont des commentaires et sont ignorées par le programme. On peut mettre des commentaires entre les sections, mais pas à l’intérieur d’une section. Chaque section est ensuite complétée par des lignes de données réelles ou entières, de mots clés, qui définissent les paramètres de la simulation.

Exemple de ligne avec entête, code et argument

! voici une ligne avec entête, code et argument
MAME    1    1

La première ligne est une ligne de commentaire. La seconde ligne est une ligne avec un entête. Elle commence par l’entête MAME, suivi de 2 entiers 1 et 1qui définissent le code et l’argument.

2.2.2 Définition des paramètres physiques: PHYS

L’entête PHYS permet de définir les paramètres physiques du modèle. Le modèle est appliqué à tout le domaine de calcul. les modèles disponibles sont le modèle de Saint-Venant Section 1.2 et le modèle bifluide Section 1.3.

On sélectionne le modèle utilisé en renseignant obligatoirement le mot clé MODE, qui prend la valeur \(2\) pour le modèle bifluide et \(1\) pour le modèle de Saint-Venant.

Pour le modèle bifluide isotherme on peut au besoin définir les paramètres à valeurs réelles suivants :

GPES : Orientation du champ de gravité suivant \(1/x\), \(2/y\), \(3/z\), ou aucune \(0\) (valeur par défaut \(2.\))
PREF : Pression de référence \(p_0\) de la loi d’état Equation 1.16 (valeur par défaut \(10^5\))
CSSM : Vitesse du son artificielle \(c_0\) de la loi d’état Equation 1.16 (valeur par défaut \(20.\))
REFA : Densité de l’air \(\rho_a\) de la loi d’état Equation 1.16 (valeur par défaut \(1.\))
REFW : Densité de l’eau \(\rho_w\) de la loi d’état Equation 1.16 (valeur par défaut \(1000.\))
SHAR : Coefficient de raidissement d’interface Section 1.3.3 (valeur par défaut \(0.\))

Pour le modèle de Saint-Venant on peut au besoin définir les paramètres suivants :

WLTR : Valeur seuil de définition de la zone sèche (valeur par défaut \(10^{-4}\))
FRMO : Prise en compte de la friction. \(0\) pas de friction, \(1\) Manning-Strickler, 2/Darcy-Weisbach (valeur par défaut \(0\)). La valeur du coefficient de friction qui peut varier spatialement est définie ultérieurement dans la section BATH.
BAGR : Le gradient de la bathymétrie est soit donné (par une fonction utilisateur ou par interpolation bilinéaire) BAGR=0, soit calculé par la méthode de Barth BAGR=1 (valeur par défaut \(0\)).

Exemple de définition des paramètres pour le modèle bifluide

PHYS 0
MODE 2.
SHAR 0.01

on définit ainsi un modèle bifluide pour un écoulement air-eau avec la gravité suivant \(y\) avec un coefficient de raidissement d’interface de \(0.01\).

Exemple de définition des paramètres pour le modèle de Saint-Venant

PHYS 0
MODE 1.
FRMO 1.

on définit ainsi un modèle d’écoulement en eaux peu profondes avec une friction de type Manning-Strickler.

2.2.3 Définition du maillage maître : MAME

L’entête MAME permet de définir le maillage maître. Pour rappel, ce maillage doit être conforme! CERF dispose d’un mailleur rudimentaire (code \(1\)) et lit les fichiers ascii de maillages au format GMSH V2.2 (code \(2\)).

Le maillage réalisé par CERF est un maillage cartésien, il faut définir sur une ligne les limites du domaine et sur une autre ligne la discrétisation dans chaque direction.

Pour un maillage “1D” : argument \(0\)
- 1 ligne constituée de 2 réels : \(x_{min}\), \(x_{max}\)
- 1 ligne constituée de 1 entier : \(n_x\)
Pour un maillage “2D” : argument \(1\)
- 1 ligne constituée de 4 réels : \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\)
- 1 ligne constituée de 2 entiers : \(n_x\), \(n_y\)
Pour un maillage “3D” : argument \(2\)
- 1 ligne constituée de 6 réels : \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\), \(z_{min}\), \(z_{max}\)
- 1 ligne constituée de 3 entiers : \(n_x\), \(n_y\), \(n_z\)

En 1D, les dimensions suivant \(y\) et \(z\) sont déterminées automatiquement par CERF, telles que \(y_{min} = z_{min} = - \frac{x_{max}-x_{min}}{2 n_x}\) et \(y_{max} = z_{max} = \frac{x_{max}-x_{min}}{2 n_x}\).
En 2D, la dimension suivant \(z\) est déterminée automatiquement par CERF, telle que \(z_{min} = - Min \left( \frac{x_{max} - x_{min}}{2 n_x} , \frac{y_{max} - y_{min}}{2 n_y} \right)\) et \(z_{max} = Min \left( \frac{x_{max} - x_{min}}{2 n_x} , \frac{y_{max} - y_{min}}{2 n_y} \right)\).

Exemple de définition d’un maillage maître via CERF

MAME    1    1
0. 1.  0.  1.
2 2

On définit ainsi un maillage “2D”, constitué de 4 blocs de forme hexagonale, 2 suivant \(x\), 2 suivant \(y\) et 1 suivant \(z\). Les blocs sont de taille \(0.5 \times 0.5\) suivant \(x\) et \(y\). La dimension suivant \(z\) est déterminée automatiquement par CERF

Pour des maillages plus complexes, on peut utiliser un maillage généré par un mailleur externe, tel que GMSH. Dans ce cas, il faut définir le maillage dans un fichier au format GMSH V2.2. L’entête MAME doit donc être affectée du code \(2\) et la ligne suivante contient le nom du fichier qui doit impérativement se trouver dans le répertoire exec.

Exemple de définition d’un maillage maître via GMSH

MAME    2    0
toto.msh

On définit ainsi un maillage “2D” à partir du fichier toto.msh au format GMSH V2.2.

2.2.4 Définition des conditions initiales: INIT

L’entête INIT permet de définir les conditions initiales du problème à traiter. On peut définir les conditions initiales pour le cas du tube à choc (code \(0\)), par une fonction définie par l’utilisateur (code \(1\)) ou par zones (code \(2\)).

Pour rappel, les variables primitives du modèle de Saint-Venant sont au nombre de \(n_{dof}=3\) : \(h\), \(u\), \(v\).
Pour rappel, les variables primitives du modèle bifluide sont au nombre de \(n_{dof}=5\) : \(\rho\), \(u\), \(v\), \(w\), \(p\).

Pour une initialisation “tube à choc” : code \(0\)
L’argument est \(0\). Puis:
- 1 ligne constituée de \(2\) réels pour le modèle de Saint-Venant (\(h\), \(u\)) ou \(3\) réels pour le modèle bifluide (\(\rho\), \(u\), \(p\)) à l’instant initial à “gauche” (\(x<0\))
- 1 ligne constituée de \(2\) réels pour le modèle de Saint-Venant (\(h\), \(u\)) ou \(3\) réels pour le modèle bifluide (\(\rho\), \(u\), \(p\)) à l’instant initial à “droite” (\(x>0\))
Pour une initialisation par fonction utilisateur : code \(1\)
L’argument définit le numéro de la fonction utilisateur, écrit dans la routine ~/CERF/sources/PHY/USER/fct_iniw.f90.
Pour une initialisation par zones : code \(2\)
L’argument définit le nombre de zone à créer. L’ordre de définition des zones est important. Cela permet d’“imbriquer” les zones. Ainsi, il est recommandé de définir la première zone couvrant largement le domaine d’étude. Puis pour chaque zone on utilise 2 lignes :
- 1 ligne constituée de 6 réels pour définir la zone : \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\), \(z_{min}\), \(z_{max}\)
- 1 ligne constituée de \(n_{dof}\) réels définissant les variables primitives à l’instant initial

Tip 2.1: Exemple d’initialisation par zones

INIT    2    2
-1. 4.1 -1. 3.1 -1. 1.
1. 0. 0. 0.  1.e5
-1. 1. -1. 2. -1. 1.
1000. 0. 0. 0.  1.e5

Dans cet exemple, on cherche à initialiser un problème de “rupture de barrage”.Dans un domaine “2D” de \(4 \times 3\) rempli d’air, on initialise une colonne d’eau à gauche de hauter \(2\) et largeur \(1\). On définit alors 2 zones. La première zone couvre largement le domaine entier et la seconde le domaine occupé par l’eau. Dans tout le domaine on initialise \(\rho=1\), \(\overrightarrow{u}=\overrightarrow{0}\) et \(p_0=10.^5\). Par la deuxième zone, dans la partie occupée par l’eau, on initialise \(\rho=1000\), \(\overrightarrow{u}=\overrightarrow{0}\) et \(p_0=10.^5\).

Important

Dans le cas où une fonction utilisateur est utilisée pour l’initialisation, il est nécessaire de relancer la compilation et l’édition de lien par la commande make!

2.2.5 Définition de la bathymétrie et de la friction : BATH

L’entête BATH permet de définir les paramètre de la bathymétrie et de la friction dans le cas, bien évidemment où le modèle de Saint-Venant est choisi.

Dans le cas où l’on considère un fond plat sans friction : code \(0\)
Dans le cas où l’on considère une bathymétrie et une friction définies par une fonction utilisateur : code \(1\)
L’argument définit le numéro de la fonction utilisateur, écrit dans la routine ~/CERF/sources/PHY/USER/fct_bathy.f90.
Dans le cas où l’on considère une bathymétrie et une friction définie bi-linéairement par bloc : code \(2\)
L’argument \(0\) permet de lire le fichier et l’argument \(-1\) permet de le créer. Sur la ligne suivante on indique le nom du fichier ASCII contenant les informations de la bathymétrie et de la friction. Ce fichier doit se trouver dans le répertoire exec. Lors de la création (argument \(-1\)) le fichier est constitué de 2 colonnes contenant les coordonnées \(x\) et \(y\) des quatre sommets de chaque bloc du maillage maître. L’utilisateur doit ensuite compléter le fichier, en rajoutant deux colonnes de réels indiquant pour chaque coordonnées les valeurs de la bathymétrie et de la friction.

2.2.6 Définition des conditions aux limites : COND

L’entête COND permet de définir les conditions aux limites du problème. Les conditions aux limites sont définies par un numéro (écrit sur une ligne) et éventuellement des valeurs réelles (écrites sur une autre ligne). Les conditions aux limites disponibles sont :

0 : condition de sortie libre (on recopie)
1 : condition miroir
2 : condition de Dirichlet sur les variables primitives. On doit alors définir les valeurs des \(n_{dof}\) variables primitives sur la ligne suivante. Si la valeur \(10^{20}\) est utilisée, alors la variable sera considérée comme libre.
3 : condition définie par l’utilisateur. L’utilisateur doit alors définir la fonction de condition aux limites dans la routine ~/CERF/sources/PHY/USER/fct_cond.f90. Sur la ligne suivante, on définit le numéro de la fonction utilisateur.
4 : condition de Dirichlet sur les variables conservatives. On doit alors définir les valeurs des \(n_{dof}\) variables conservatives sur la ligne suivante. Si la valeur \(10^{20}\) est utilisée, alors la variable sera considérée comme libre.
999 : Aucune condition aux limites. Les flux ne sont pas calculés.

La définition des conditions aux limites sur les bords du domaine dépend alors du type de maillage maître utilisé :

Dans le cas où l’on considère un “tube à choc” : code \(0\)
On est dans le cas où la section MAME a pour code \(1\), argument \(0\), et la section INIT a pour code \(0\). Dans ce cas, aucune définition n’est nécessaire.
Dans le cas où l’on considère un maillage “2D” : code \(1\)
On est dans le cas où la section MAME a pour code \(1\), argument \(1\). On définit alors les conditions aux limites sur les bords du domaine dans l’ordre \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\). Pour chaque bord, on utilise 1 ou 2 lignes pour définir la condition aux limites.
Dans le cas où l’on considère un maillage “3D” : code \(2\)
On est dans le cas où la section MAME a pour code \(1\), argument \(2\). On définit alors les conditions aux limites sur les bords du domaine dans l’ordre \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\), \(z_{min}\), \(z_{max}\). Pour chaque bord, on utilise 1 ou 2 lignes pour définir la condition aux limites.
Dans le cas où l’on considère un maillage “GMSH” : code \(3\)
On est dans le cas où la section MAME a pour code \(2\). On utilise alors les numéros de “zones” définis par GMSH. L’argument définit le nombre de zones à traiter. Ces zones correspondent aux bords du domaine. Pour chaque zone, on utilise 1 ou 2 lignes pour définir la condition aux limites.

Exemple de conditions aux limites

COND    1    0
1
1
1
1

Dans cet exemple, on applique des conditions “miroir” sur les 4 bords d’un domaine “2D” rectangulaire.

2.2.7 Définition du maillage : MESH

L’entête MESH permet de définir le maillage du domaine, c’est à dire la discrétisation des blocs définis dans la section MAME. De plus, on définit les paramètres de (dé)raffinement de maillage. Le code par défaut est \(0\).

On peut alors définir/modifier les mots clés suivants :

NBDS : Nombre de domaines à créer, c’est-à-dire nombre de processus MPI (valeur par défaut \(1.\))
MARL : Niveau maximum de raffinement (“MAximal Refinement Level”) (valeur par défaut \(0.\))
COPA : Valeur seuil du critère de déraffinement (“mesh COarsening PArameter”) (valeur par défaut \(0.002\))
REPA : Valeur seuil du critère de raffinement (“mesh REfinement PArameter”) (valeur par défaut \(0.02\))
FDRA : Numéro de la fonction utilisateur définissant le raffinement à appliquer. Cette fonction est définie dans la routine ~/CERF/sources/UTI/USER/fct_mesh.f90
NZRA :Nombre de zones définissant le raffinement à appliquer (default 1.). Suivi, pour chaque zone, de \(1\) entier et \(6\) réels définissant le niveau de raffinement à appliquer à chacun des blocs de la zone et les limites de la zone \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\), \(z_{min}\), \(z_{max}\).

Tip 2.2: Exemple de raffinement par zones

MESH 0
NBDS 4
MARL 3
COPA 0.8
REPA 1.
NZRA 3
0 -1. 4.1 -1. 3.1 -1. 1.
3 -1. 1.25 -1. 2.25 -1. 1.
0 -1. .75 -1. 1.75 -1. 1.

On reprend l’exemple de “rupture de barrage” Tip 2.2. Dans un domaine “2D” de \(4 \times 3\) rempli d’air, on considère une colonne d’eau à gauche de hauteur \(2\) et largeur \(1\). L’objectif est de raffiner autour de l’interface air-eau. On définit alors 3 zones. La première zone couvre largement le domaine entier pour affecter un niveau de raffinement \(0\). La seconde couvre le domaine occupé par l’eau avec une marge de \(0.25\), auquel on affecte le niveau maximal de raffinement \(3\). Et enfin, la troisième couvre le domaine occupé par l’eau avec une marge de \(-0.25\), auquel on affecte le niveau minimal de raffinement \(0\), afin de minimiser le nombre de cellules. CERF ajustera automatiquement (c.a.d sans intervention de l’utilisateur) le niveau de maillage entre les niveaux \(0\) et \(3\) afin de respecter les critères imposés par le mailleur. Par ailleurs, on décompose le domaine en 4 domaines et on modifie les paramètres de gestion du critère de raffinement de maillage Section 1.1.3.3.

2.2.8 Définition d’“obstacle” : OBST

L’entête OBST permet de définir un ensemble de cellules à qui on impose une pénalisation de type “fluide rigide” dans le cas, bien évidemment où le modèle bi-fluide est choisi. Le code par défaut est \(0\) et l’argument définit le nombre d’obstacles à traiter.
Pour chaque obstacle on écrit sur une ligne : un nom de fichier, la densité de l’obstacle et le type de pénalisation.

nom de fichier : il s’agit d’une chaîne de caractère (20 caractères max) définissant le nom du fichier ASCII contenant le maillage de l’enveloppe de l’obstacle avec des éléments triangulaires au format .OBJ. Ce fichier doit se trouver dans le répertoire exec.
densité de l’obstacle : il s’agit d’un réel définissant la densité de l’obstacle. Cette densité est nécessairement \(\rho_a \leq \rho_{obs} \leq \rho_w\).
type de pénalisation : il s’agit d’un entier définissant le type de pénalisation. Les types de pénalisation disponibles sont :
- -1 : pénalisation de type “fixe”. On impose une vitesse nulle.
- 0 : pénalisation de type “libre”. L’obstacle a un comportement de solide rigide libre.
- >0 : pénalisation de type “imposée”. L’obstacle a un comportement de solide rigide auquel on impose la vitesse du centre de gravité et la vitesse de rotation. La valeur de l’entier définit le numéro de la fonction utilisateur définissant le mouvement dans la routine ~/CERF/sources/PHY/USER/fct_mvsol.f90.

Exemple de fichier obstacle au format .obj

v 0. 0. 0.
v 1. 0. 0.
v 1. 1. 0.
v 0. 1. 0.
v 0. 0. 1.
v 1. 0. 1.
v 1. 1. 1.
v 0. 1. 1.
f 1 2 3
f 1 3 4 
f 2 6 7
f 2 7 3
f 6 5 7
f 5 8 7 
f 5 1 4
f 5 4 8
f 3 4 7
f 4 7 8
f 2 5 6
f 2 1 5

Dans cet exemple, on définit un obstacle de forme cubique de côté \(1\) centré en \((0.5,0.5,0.5)\). On définit les sommets de l’obstacle puis les faces de l’obstacle. Les sommets sont définis par la lettre v suivie des coordonnées du sommet. Les faces sont définies par la lettre f suivie des indices des sommets de la face. La figure ci-après illustre la forme de l’obstacle ainsi défini.

2.2.9 Définition des paramètres numériques: NUME

L’entête NUME permet de définir les paramètres numériques du problème à traiter. Le code par défaut est \(0\).

On peut alors définir/modifier les mots clés suivants:

TINT : Intervalle de temps du calcul (Time INTerval) (valeur par défaut \(0.\))
CCFL : Coefficient CFL Important 1.1 (valeur par défaut \(0.9\))
TDOR : Ordre de la discrétisation temporelle (Time Discretization ORder) 1 ou 2 (valeur par défaut \(1.\))
SDOR : Ordre de la discrétisation spatiale (Space Discretization ORder) 1 ou 2 (valeur par défaut \(1.\))
LIMI : Type de limiteur 0/Barth, 1/Cartesian (valeur par défaut \(0.\))
NPRO : Nombre de sondes < 10 (valeur par défaut \(0.\)). Puis pour chaque sonde une ligne contenant 3 réels (coordonnées \(x\), \(y\), \(z\) de la sonde)
SAVE : Type de sauvegarde 0/Non, 1/Oui. Le chiffre des unités se rapporte à la sauvegarde dans les fichiers cerfbin-xxx. Le chiffre des dizaines se rapporte à une sauvegarde au format gnuplot en 1D. (valeur par défaut \(01.\))

2.3 Les fichiers sources de CERF

2.3.1 Structure et modules

Comme illustré sur Figure 2.1, le code source de CERF est organisé en plusieurs répertoires:

./sources/PHY contient toutes les routines de plus bas niveau concernant la manipulation des variables et entités physiques. Les variables physiques globales et les types de données (au sens Fortran 90), comme les degrés de liberté, leur gradients, les flux ou les caractéristiques physiques, sont définis dans le module phy_typ (./sources/PHY/mod_phy_typ.f90). Le module phy (./sources/PHY/mod_phy.f90), quant à lui, contient le module phy_typ ainsi que toutes les interfaces des routines contenues dans le répertoire PHY. Lors de la compilation, le résultat de compilation des routines de ce répertoire est archivé dans la librairie ./lib/lib_PHY.a.
./sources/GEO contient toutes les routines concernant la manipulation des variables et entités géométriques: calcul des flux aux interface, calcul des termes sources, …. Les variables géométriques globales et les types de données (au sens Fortran 90), comme la liste des faces, la liste des cellules, le maillage, … etc …, sont définis dans le module geo_typ (./sources/GEO/mod_geo_typ.f90). Le module geo_typ contient le module phy. Ils sont imbriqués. Le module geo (./sources/GEO/mod_geo.f90), quant à lui, contient le module geo_typ ainsi que toutes les interfaces des routines contenues dans le répertoire GEO. Lors de la compilation, le résultat de compilation des routines de ce répertoire est archivé dans la librairie ./lib/lib_GEO.a.
./sources/NUM contient toutes les routines de plus haut niveau concernant la manipulation des variables et entités numériques: algorithme rk2, sauvegarde,communication MPI, …. Les variables numériques globales et les types de données (au sens Fortran 90), comme le “calcul”, sont définis dans le module num_typ (./sources/NUM/mod_num_typ.f90). Le module num_typ contient le module geo. Ils sont imbriqués. Le module num (./sources/NUM/mod_num.f90), quant à lui, contient le module num_typ ainsi que toutes les interfaces des routines contenues dans le répertoire NUM. Lors de la compilation, le résultat de compilation des routines de ce répertoire est archivé dans la librairie ./lib/lib_NUM.a.
./sources/UTI contient les programmes et les toutes les routines nécessaires au pré et post-traitement, donc en particulier à la gestion du maillage AMR. Le module uti (./sources/UTI/mod_uti.f90), contient le module num ainsi que toutes les interfaces des routines contenues dans le répertoire UTI. Lors de la compilation, le résultat de compilation des routines de ce répertoire est archivé dans la librairie ./lib/lib_UTI.a.

Les modules phy, geo, num et uti sont imbriqués et interdépendants. Les types de données qui y sont définies sont les outils de base de la méthode des volumes finis. Dans le cadre de la gestion de maillages AMR, il a été necessaire de développer de nouveaux outils qui ont été regroupés dans deux modules.

zorder (./sources/UTI/mod_zorder.f90) : ce module contient les outils de gestion de la structure de données “z-order” qui est utilisée pour gérer le maillage AMR. Il contient l’ensemble des routines nécessaire à la gestion des Code de Morton.
msh (./sources/UTI/mod_msh.f90) : ce module contient les outils de gestion de la structure de données “maillage” qui est utilisée pour gérer le maillage AMR. Il contient l’ensemble des routines nécessaire à la gestion du maillage AMR. Les strucutures de données du code volumes finis sont stockées dans des tableaux “fixes” par soucis de performance. La gestion des graphes de maillage, par contre est plus complexe et nécessite des structures de données dynamiques avec des listes chainées. Le module msh contient l’ensemble des outils nécessaires à la gestion de ces structures de données.

2.3.2 Le graphe de dépendance du programme principal

Nous présentons ci-apprès le graphe de dépendance du programme principal cerf (hormis les routines MPI et les routines d’affichage). Les routines dépendant du module phy sont entourées de vert, les routines dépendant du module geo sont entourées de bleu et les routines dépendant du module num sont entourées de rouge. La documentation au format html permet d’accéder directement au code source de la routine en cliquant sur le nom de la routine dans le graphe Figure 2.3.

flowchart LR
    A[cerf] --> B(init_calc)
    B --> AA(empty_mesh)
    A --> E(rk2)
    A --> C(save_1d)
    A --> D(save_calc)
    E --> F(dtloc)
    E --> G(synchro_mpi)
    E --> H(gradprim)
    E --> I(gradlim)
    E --> J(gradlimxy)
    E --> K(synchro_w)
    E --> L(entropie)
    E --> M(calc_flux)
    E --> N(calc_source)
    E --> O(friction)
    E --> P(sharp)
    E --> Q(u_penalisation)
    F --> R(velcf)
    R --> T(vitson)
    M --> U(wext)
    M --> V(prim2bal)
    M --> W(bal2prim)
    M --> X(fluxnum)
    M --> Y(fluxnumnoncons)
    Q --> Z(raycasting)
    U --> W
    U --> V
    C --> W
    C --> AB(riemisot)
    C --> AC(svriemann)
    H --> U
    I --> U
    J --> U
    B --> S(get_calc)
    N --> AD(sources)
    O --> V
    P --> W
    Q --> V
    Q --> AE(fct_mvsol)

    classDef num  color:#000000,stroke:#FF0000,stroke-width:4px
    classDef geo  color:#000000,stroke:#0000FF,stroke-width:4px
    classDef phy  color:#000000,stroke:#00FF00,stroke-width:4px
    classDef uti  color:#000000,stroke:#800080,stroke-width:4px
    class A,B,C,D,E,F,G,K,M,N,O,P,Q,S,Z num
    class H,I,J,AA geo
    class L,U,V,W,X,Y,AB,AC,R,T,AD,AE phy
    %%class G uti

  click A href "../robodoccerf/NUM/cerf_f90.html" _blank
  click B href "../robodoccerf/NUM/init_calc_f90.html" _blank
  click E href "../robodoccerf/NUM/rk2_f90.html" _blank
  click C href "../robodoccerf/NUM/save_1d_f90.html" _blank
  click D href "../robodoccerf/NUM/save_calc_f90.html" _blank
  click F href "../robodoccerf/NUM/dtloc_f90.html" _blank
  click G href "../robodoccerf/GEO/synchro_mpi_f90.html" _blank
  click H href "../robodoccerf/GEO/gradprim_f90.html" _blank
  click I href "../robodoccerf/GEO/gradlim_f90.html" _blank
  click J href "../robodoccerf/GEO/gradlimxy_f90.html" _blank
  click K href "../robodoccerf/NUM/synchro_w_f90.html" _blank
  click L href "../robodoccerf/PHY/entropie_f90.html" _blank
  click M href "../robodoccerf/NUM/calc_flux_f90.html" _blank
  click N href "../robodoccerf/NUM/calc_source_f90.html" _blank
  click O href "../robodoccerf/NUM/friction_f90.html" _blank
  click P href "../robodoccerf/NUM/sharp_f90.html" _blank
  click Q href "../robodoccerf/NUM/u_penalisation_f90.html" _blank
  click R href "../robodoccerf/PHY/velcf_f90.html" _blank
  click S href "../robodoccerf/NUM/get_calc_f90.html" _blank
  click T href "../robodoccerf/PHY/vitson_f90.html" _blank
  click U href "../robodoccerf/PHY/wext_f90.html" _blank
  click V href "../robodoccerf/PHY/prim2bal_f90.html" _blank
  click W href "../robodoccerf/PHY/bal2prim_f90.html" _blank
  click X href "../robodoccerf/PHY/fluxnum_f90.html" _blank
  click Y href "../robodoccerf/PHY/fluxnumnoncons_f90.html" _blank
  click Z href "../robodoccerf/NUM/raycasting_f90.html" _blank
  click AA href "../robodoccerf/GEO/empty_mesh_f90.html" _blank
  click AB href "../robodoccerf/PHY/riemisot_f90.html" _blank
  click AC href "../robodoccerf/PHY/svriemann_f90.html" _blank
  click AD href "../robodoccerf/PHY/sources_f90.html" _blank
  click AE href "../robodoccerf/PHY/USER/fct_mvsol_f90.html" _blank

Figure 2.3: Graphe de dépendance des routines de CERF

2.3.3 Le graphe de dépendance du programme de pré-traitement

Nous présentons ci-apprès le graphe de dépendance du programme de pré-traitement cerf_input (hormis les routines MPI et les routines d’affichage). Les routines dépendant du module phy sont entourées de vert, les routines dépendant du module geo sont entourées de bleu, les routines dépendant du module num sont entourées de rouge et les routines dépendant du module uti sont entourées de violet. La documentation au format html permet d’accéder directement au code source de la routine en cliquant sur le nom de la routine dans le graphe Figure 2.4.

flowchart LR
    A[cerf_input] --> B(read_phys)
    A --> C(read_cond)
    A --> D(read_init)
    A --> E(read_bath)
    A --> F(read_obst)
    A --> G(read_mame)
    A --> H(read_nume)
    A --> I(read_mesh)
    A --> J(block2mesh)
    A --> K(save_calc)
    A --> L(amr2tec)
    J --> P(init_def_bloc)
    J --> R(splitdom_Z)
    J --> S(inter)
    J --> T(empty_mesh)
    J --> U(initialise)
    J --> V(mesh1d)
    J --> W(mesh2d)
    J --> X(mesh3d)
    J --> Y(init_mesh)
    J --> Z(trivertex)
    J --> AA(ini_w)
    J --> K
    J --> AC(copy_sol)
    C --> AD(prim2bal)
    C --> AE(bal2prim)
    D --> AD
    F --> M(read_obj)
    G --> N(mame2bloc)
    G --> O(read_gmsh)
    P --> Q(fct_mesh)
    V --> AF(psr)
    V --> AG(pni)
    V --> AH(volcel)
    W --> AF
    W --> AG
    W --> AH
    X --> AF
    X --> AG
    X --> AH
    Y --> AI(triangle)
    AA --> AJ(fct_iniw)
    AA --> AK(fct_bathy)
    AC --> AL(empty_sol)
    N --> ZZ((Module zorder))
    O --> ZZ
    O --> MM((Module msh))
    Z --> ZZ
    classDef num  color:#000000,stroke:#FF0000,stroke-width:4px
    classDef geo  color:#000000,stroke:#0000FF,stroke-width:4px
    classDef phy  color:#000000,stroke:#00FF00,stroke-width:4px
    classDef uti  color:#000000,stroke:#800080,stroke-width:4px
    class B,C,D,E,H,I,K,L,N,R,S,AA,AB,AC num
    class M,T,U,V,W,X,Y,Z,AF,AG,AH,AL geo
    class Q,AD,AE,AJ,AK phy
    class A,F,G,J,O,P uti
 
  click A href "../robodoccerf/UTI/PRE/cerf_input_f90.html" _blank
  click B href "../robodoccerf/UTI/PRE/read_phy_f90.html" _blank
  click C href "../robodoccerf/UTI/PRE/read_cond_f90.html" _blank
  click D href "../robodoccerf/UTI/PRE/read_init_f90.html" _blank
  click E href "../robodoccerf/UTI/PRE/read_bath_f90.html" _blank
  click F href "../robodoccerf/UTI/PRE/read_obst_f90.html" _blank
  click G href "../robodoccerf/UTI/PRE/read_mame_f90.html" _blank
  click H href "../robodoccerf/UTI/PRE/read_nume.html" _blank
  click I href "../robodoccerf/UTI/PRE/read_mesh_f90.html" _blank
  click J href "../robodoccerf/UTI/PRE/block2mesh_f90.html" _blank
  click K href "../robodoccerf/NUM/save_calc_f90.html" _blank
  click L href "../robodoccerf/UTI/AMR/amr2tec_f90.html" _blank
  click M href "../robodoccerf/UTI/PRE/read_obj_f90.html" _blank
  click N href "../robodoccerf/UTI/PRE/mame2bloc_f90.html" _blank
  click O href "../robodoccerf/UTI/PRE/read_gmsh_f90.html" _blank
  click P href "../robodoccerf/UTI/PRE/init_def_bloc_f90.html" _blank
  click Q href "../robodoccerf/UTI/USER/fct_mesh_f90.html" _blank
  click R href "../robodoccerf/UTI/PRE/splitdom_Z_f90.html" _blank
  click S href "../robodoccerf/UTI/PRE/inter_f90.html" _blank
  click T href "../robodoccerf/GEO/empty_mesh_f90.html" _blank
  click U href "../robodoccerf/UTI/PRE/initialise_f90.html" _blank
  click V href "../robodoccerf/GEO/mesh1d_f90.html" _blank
  click W href "../robodoccerf/GEO/mesh2d_f90.html" _blank
  click X href "../robodoccerf/GEO/mesh3d_f90.html" _blank
  click Y href "../robodoccerf/UTI/PRE/init_mesh_f90.html" _blank
  click Z href "../robodoccerf/UTI/PRE/trivertex_f90.html" _blank
  click AA href "../robodoccerf/UTI/PRE/ini_w_f90.html" _blank
  click AC href "../robodoccerf/UTI/PRE/copy_sol_f90.html" _blank
  click AD href "../robodoccerf/PHY/prim2bal_f90.html" _blank
  click AE href "../robodoccerf/PHY/bal2prim_f90.html" _blank
  click AF href "../robodoccerf/GEO/fonctions_f90.html" _blank
  click AG href "../robodoccerf/GEO/fonctions_f90.html" _blank
  click AH href "../robodoccerf/GEO/fonctions_f90.html" _blank
  click AI href "../robodoccerf/GEO/triangle_f90.html" _blank
  click AJ href "../robodoccerf/PHY/USER/fct_iniw_f90.html" _blank
  click AK href "../robodoccerf/PHY/USER/fct_bathy_f90.html" _blank
  click AL href "../robodoccerf/UTI/PRE/empty_sol_f90.html" _blank
  click MM href "../robodoccerf/UTI/mod_msh_f90.html" _blank
  click ZZ href "../robodoccerf/UTI/mod_zorder_f90.html" _blank

Figure 2.4: Graphe de dépendance des routines de cerf_input

2.3.4 Le graphe de dépendance du programme de modification du maillage

Nous présentons ci-apprès le graphe de dépendance du programme de de modification du maillage cerf_amr (hormis les routines MPI et les routines d’affichage). Les routines dépendant du module phy sont entourées de vert, les routines dépendant du module geo sont entourées de bleu, les routines dépendant du module num sont entourées de rouge et les routines dépendant du module uti sont entourées de violet. La documentation au format html permet d’accéder directement au code source de la routine en cliquant sur le nom de la routine dans le graphe Figure 2.5.

flowchart LR
    A[cerf_input] --> B(get_calc)
    A --> T(empty_mesh)
    A --> AL(empty_sol)
    A --> C(critraf)
    C --> D(critphy)
    A --> K(save_calc)
    A --> L(amr2tec)
    A --> R(splitdom_Z)
    A --> S(inter)
    A --> AC(copy_sol)
    A --> V(mesh1d)
    A --> W(mesh2d)
    A --> X(mesh3d)
    A --> Y(init_mesh)
    Y --> AI(triangle)
    A --> Z(trivertex)
    Z --> ZZ((Module zorder))
    A --> E(proddl)
    E --> AK(fct_bathy)
    E --> AD(prim2bal)
    C --> AD(prim2bal)
    V --> AF(psr)
    V --> AG(pni)
    V --> AH(volcel)
    W --> AF
    W --> AG
    W --> AH
    X --> AF
    X --> AG
    X --> AH
    A --> F(raycasting)
    A --> G(save_obj)
    classDef num  color:#000000,stroke:#FF0000,stroke-width:4px
    classDef geo  color:#000000,stroke:#0000FF,stroke-width:4px
    classDef phy  color:#000000,stroke:#00FF00,stroke-width:4px
    classDef uti  color:#000000,stroke:#800080,stroke-width:4px
    class B,C,K,L,R,S,AC,E,F num
    class T,AL,V,W,X,AF,AG,AH,Y,Z,G geo
    class D,AK,AD phy
    class A uti

  click A href "../robodoccerf/UTI/AMR/cerf_amr_f90.html" _blank
  click T href "../robodoccerf/GEO/empty_mesh_f90.html" _blank
  click B href "../robodoccerf/NUM/get_calc_f90.html" _blank
  click AL href "../robodoccerf/UTI/PRE/empty_sol_f90.html" _blank
  click C href "../robodoccerf/UTI/AMR/critraf_f90.html" _blank
  click D href "../robodoccerf/PHY/critphy_f90.html" _blank
  click K href "../robodoccerf/NUM/save_calc_f90.html" _blank
  click L href "../robodoccerf/UTI/AMR/amr2tec_f90.html" _blank
  click R href "../robodoccerf/UTI/PRE/splitdom_Z_f90.html" _blank
  click S href "../robodoccerf/UTI/PRE/inter_f90.html" _blank
  click AC href "../robodoccerf/UTI/PRE/copy_sol_f90.html" _blank
  click V href "../robodoccerf/GEO/mesh1d_f90.html" _blank
  click W href "../robodoccerf/GEO/mesh2d_f90.html" _blank
  click X href "../robodoccerf/GEO/mesh3d_f90.html" _blank
  click AF href "../robodoccerf/GEO/fonctions_f90.html" _blank
  click AG href "../robodoccerf/GEO/fonctions_f90.html" _blank
  click AH href "../robodoccerf/GEO/fonctions_f90.html" _blank
  click Y href "../robodoccerf/UTI/PRE/init_mesh_f90.html" _blank
  click AI href "../robodoccerf/GEO/triangle_f90.html" _blank
  click Z href "../robodoccerf/UTI/PRE/trivertex_f90.html" _blank
  click E href "../robodoccerf/NUM/proddl_f90.html" _blank
  click AK href "../robodoccerf/PHY/USER/fct_bathy_f90.html" _blank
  click AD href "../robodoccerf/PHY/prim2bal_f90.html" _blank
  click F href "../robodoccerf/NUM/raycasting_f90.html" _blank
  click G href "../robodoccerf/NUM/save_obj_f90.html" _blank
  click ZZ href "../robodoccerf/UTI/mod_zorder_f90.html" _blank

Figure 2.5: Graphe de dépendance des routines de cerf_amr