2  User Guide

This chapter describes the installation of the CERF software, as well as its use.

2.1 Software installation

2.1.1 Prerequisites

CERF is software written in Fortran 90 using the MPI library for communication between the different processes.

Important

It is therefore necessary to have:
- a Linux operating system or emulator (Ubuntu, CentOS, WSL on Windows 10 or 11, Mac OS, ….)
- a Fortran 90 compiler (gfortran, ifort, …)
- the MPI library (OpenMPI)

The output files of CERF are in Tecplot format (VTK to come). It is therefore recommended to have visualization software such as ParaView or Visit.

2.1.2 Installation

To install CERF, after downloading the archive ‘cerf_v1.0.tar’, simply unpack it in a directory of your choice.

tar xvf cerf_v1.0.tar .

The unpacked archive will then present a directory tree as illustrated in Figure 2.1.

Figure 2.1: CERF directory tree

The main CERF directory contains 4 subdirectories: doc, sources, lib and exec.

  • the doc directory contains the software documentation
  • the sources directory contains the software sources
  • the lib directory contains the libraries created during compilation, required to build the executables
  • the exec directory contains all the software’s executables. This is the working directory

To install CERF, simply go to the exec directory and run the Makefile.

cd CERF/exec
make
Note

By default, the Makefile uses the gfortran compiler and the OpenMPI library. However, these settings can be changed in the Makefile.

  • Parameter FC = “gfortran” or “ifort” or ….. for a sequential computation
  • Parameter FC = “mpif90” or ….. for a parallel computation
  • Parameter MPI = “_MPI” or “NONE_MPI” depending on whether the MPI library is installed or not
  • Parameter FFLAGS to redefine the compilation settings
Note

The Makefile is configured to recompile only newly created or modified source files. In the event of a full recompilation, for example following a change of machine, it is advisable to clean the object files and executables before rerunning the Makefile, using the command:

make clean

Once the Makefile has finished running, the CERF executables are created in the exec directory: cerf, cerf_amr, cerf_input and cerf2tec.

Note

Depending on the operating system used, the executables may or may not have the “.exe” extension.

2.1.3 Running a computation

Figure 2.2: Steps of a CERF computation

As illustrated in Figure 2.2, running a CERF computation involves several steps. A pre-processing phase is used to generate the mesh, the initial conditions of the computation, and the computation parameters. This phase is carried out by the executable cerf_input. Once the mesh has been generated, the computation is performed by the executable cerf, and the mesh can be modified by the executable cerf_amr. Finally, the executable cerf2tec converts the output files to Tecplot format for a post-processing phase.

  • cerf_input
    As input, cerf_input reads a configuration file .inp in a format specific to CERF, in which the physical and numerical parameters of the model to be processed, the mesh, the initial conditions, the boundary conditions, etc., are defined. If the mesh is defined by a file in GMSH V2.2 format, it will also read the .msh file. If rigid fluid penalizations are defined, it will also read the objects in the .obj files.
    As output, cerf_input generates a binary file cerfbin_000 containing the definition of the master mesh, and as many binary files cerfbin_* as required domains, containing all the domain information: parameters, mesh, degrees of freedom, boundary conditions, etc.

  • cerf
    As input, cerf reads the binary files cerfbin_* generated by cerf_input or modified by cerf_amr. It then performs a computation in parallel (via MPI processes) on the defined domains over the required time period. During this step, the mesh is fixed. As output, once the computation is complete, cerf updates the binary files cerfbin_* with the new values of the computed fields.

  • cerf_amr
    As input, cerf_amr reads the binary files cerfbin_* generated by cerf. It then refines the mesh according to criteria defined in the configuration file .inp. As output, cerf_amr updates the binary files cerfbin_* with the new mesh. In addition, cerf_amr generates a file cerfamr.dat containing information related to the master mesh: refinement criterion, refinement level, etc. If rigid fluid penalizations are defined, cerf_amr also generates solide_* files containing the new position of the objects.

  • cerf2tec
    As input, cerf2tec reads the binary files cerfbin_. It then converts the binary files into a single ASCII file, named cerfout.dat*, in Tecplot format for visualizing the results.

Running a computation using only command lines can become tedious. This is why scripts are often used. Below is an example of a script that lets you run a complete CERF computation with a single command. Simply modify it according to your needs.

TipExample shell script

Below is an example shell script for running a computation from the file dam.inp. This script runs the computation on 4 processors, then modifies the mesh 20 times. The output files are renamed according to the iteration so that the progress of the computation can be visualized.

#!/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 The configuration file *.inp

2.2.1 General overview

The configuration file is a text file used to define all the parameters and entities required for the simulation. It is divided into several sections, each beginning with a 4-character header. The headers, to be provided in this order, are as follows: PHYS, MAME, BATH, INIT, COND, MESH, OBST, NUME. Each header is followed on the same line by 1 or 2 integers defining the code and, if applicable, the argument. All lines starting with “!” are comments and are ignored by the program. Comments may be placed between sections, but not within a section. Each section is then completed with lines of real or integer data, or keywords, that define the simulation parameters.

TipExample line with header, code, and argument 
! here is a line with header, code, and argument
MAME    1    1

The first line is a comment line. The second line is a line with a header. It starts with the header MAME, followed by 2 integers, 1 and 1 defining the code and the argument.

2.2.2 Defining the physical parameters: PHYS

The PHYS header is used to define the physical parameters of the model. The model is applied to the entire computational domain. The available models are the Saint-Venant model Section 1.2 and the two-fluid model Section 1.3.

The model used is selected by setting the keyword MODE, which is mandatory and takes the value \(2\) for the two-fluid model and \(1\) for the Saint-Venant model.

For the isothermal two-fluid model, the following real-valued parameters can be defined as needed:

  • GPES: Orientation of the gravity field along \(1/x\), \(2/y\), \(3/z\), or none \(0\) (default value \(2.\))
  • PREF: Reference pressure \(p_0\) of the equation of state Equation 1.16 (default value \(10^5\))
  • CSSM: Artificial speed of sound \(c_0\) of the equation of state Equation 1.16 (default value \(20.\))
  • REFA: Air density \(\rho_a\) of the equation of state Equation 1.16 (default value \(1.\))
  • REFW: Water density \(\rho_w\) of the equation of state Equation 1.16 (default value \(1000.\))
  • SHAR: Interface sharpening coefficient Section 1.3.3 (default value \(0.\))

For the Saint-Venant model, the following parameters can be defined as needed:

  • WLTR: Threshold value defining the dry zone (default value \(10^{-4}\))
  • FRMO: Inclusion of friction. \(0\) no friction, \(1\) Manning-Strickler, 2/Darcy-Weisbach (default value \(0\)). The value of the friction coefficient, which may vary spatially, is defined later in the BATH section.
  • BAGR: The bathymetry gradient is either given (by a user-defined function or by bilinear interpolation) BAGR=0, or computed using the Barth method BAGR=1 (default value \(0\)).
TipExample parameter definition for the two-fluid model 
PHYS 0
MODE 2.
SHAR 0.01

This defines a two-fluid model for an air-water flow with gravity along \(y\) and an interface sharpening coefficient of \(0.01\).

TipExample parameter definition for the Saint-Venant model 
PHYS 0
MODE 1.
FRMO 1.

This defines a shallow-water flow model with Manning-Strickler-type friction.

2.2.3 Defining the master mesh: MAME

The MAME header is used to define the master mesh. As a reminder, this mesh must be conformal! CERF has a rudimentary mesh generator (code \(1\)) and reads ASCII mesh files in GMSH V2.2 format (code \(2\)).

The mesh generated by CERF is a Cartesian mesh; the domain boundaries must be defined on one line, and the discretization in each direction on another line.

  • For a “1D” mesh: argument \(0\)
    • 1 line consisting of 2 reals: \(x_{min}\), \(x_{max}\)
    • 1 line consisting of 1 integer: \(n_x\)
  • For a “2D” mesh: argument \(1\)
    • 1 line consisting of 4 reals: \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\)
    • 1 line consisting of 2 integers: \(n_x\), \(n_y\)
  • For a “3D” mesh: argument \(2\)
    • 1 line consisting of 6 reals: \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\), \(z_{min}\), \(z_{max}\)
    • 1 line consisting of 3 integers: \(n_x\), \(n_y\), \(n_z\)

In 1D, the dimensions along \(y\) and \(z\) are automatically determined by CERF, such that \(y_{min} = z_{min} = - \frac{x_{max}-x_{min}}{2 n_x}\) and \(y_{max} = z_{max} = \frac{x_{max}-x_{min}}{2 n_x}\).
In 2D, the dimension along \(z\) is automatically determined by CERF, such that \(z_{min} = - Min \left( \frac{x_{max} - x_{min}}{2 n_x} , \frac{y_{max} - y_{min}}{2 n_y} \right)\) and \(z_{max} = Min \left( \frac{x_{max} - x_{min}}{2 n_x} , \frac{y_{max} - y_{min}}{2 n_y} \right)\).

TipExample of a master mesh definition via CERF 
MAME    1    1
0. 1.  0.  1.
2 2

This defines a “2D” mesh consisting of 4 hexahedral-shaped blocks, 2 along \(x\), 2 along \(y\), and 1 along \(z\). The blocks have size \(0.5 \times 0.5\) along \(x\) and \(y\). The dimension along \(z\) is automatically determined by CERF.

For more complex meshes, a mesh generated by an external mesh generator, such as GMSH, can be used. In this case, the mesh must be defined in a file in GMSH V2.2 format. The MAME header must then be given code \(2\), and the next line contains the name of the file, which must be located in the exec directory.

TipExample of a master mesh definition via GMSH 
MAME    2    0
toto.msh

This defines a “2D” mesh from the file toto.msh in GMSH V2.2 format.

2.2.4 Defining the initial conditions: INIT

The INIT header is used to define the initial conditions of the problem to be solved. The initial conditions can be defined for the shock tube case (code \(0\)), via a user-defined function (code \(1\)), or by zones (code \(2\)).

As a reminder, the primitive variables of the Saint-Venant model number \(n_{dof}=3\): \(h\), \(u\), \(v\).
As a reminder, the primitive variables of the two-fluid model number \(n_{dof}=5\): \(\rho\), \(u\), \(v\), \(w\), \(p\).

  • For a “shock tube” initialization: code \(0\)
    The argument is \(0\). Then:
    • 1 line consisting of \(2\) reals for the Saint-Venant model (\(h\), \(u\)) or \(3\) reals for the two-fluid model (\(\rho\), \(u\), \(p\)) at the initial time on the “left” side (\(x<0\))
    • 1 line consisting of \(2\) reals for the Saint-Venant model (\(h\), \(u\)) or \(3\) reals for the two-fluid model (\(\rho\), \(u\), \(p\)) at the initial time on the “right” side (\(x>0\))
  • For an initialization via a user-defined function: code \(1\)
    The argument defines the number of the user-defined function, written in the routine ~/CERF/sources/PHY/USER/fct_iniw.f90.
  • For an initialization by zones: code \(2\)
    The argument defines the number of zones to create. The order in which zones are defined is important. It allows zones to be “nested”. It is therefore recommended to define the first zone so that it broadly covers the study domain. Then, for each zone, 2 lines are used:
    • 1 line consisting of 6 reals defining the zone: \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\), \(z_{min}\), \(z_{max}\)
    • 1 line consisting of \(n_{dof}\) reals defining the primitive variables at the initial time
Tip 2.1: Example of initialization by 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

In this example, we aim to initialize a “dam-break” problem. In a “2D” domain of \(4 \times 3\) filled with air, a column of water of height \(2\) and width \(1\) is initialized on the left. We therefore define 2 zones. The first zone broadly covers the entire domain, and the second covers the domain occupied by the water. Throughout the domain, we initialize \(\rho=1\), \(\overrightarrow{u}=\overrightarrow{0}\), and \(p_0=10.^5\). With the second zone, in the part occupied by the water, we initialize \(\rho=1000\), \(\overrightarrow{u}=\overrightarrow{0}\), and \(p_0=10.^5\).

Important

If a user-defined function is used for initialization, it is necessary to rerun compilation and linking using the make command!

2.2.5 Defining bathymetry and friction: BATH

The BATH header is used to define the bathymetry and friction parameters, naturally in the case where the Saint-Venant model is selected.

  • In the case of a flat bottom with no friction: code \(0\)
  • In the case of bathymetry and friction defined by a user-defined function: code \(1\)
    The argument defines the number of the user-defined function, written in the routine ~/CERF/sources/PHY/USER/fct_bathy.f90.
  • In the case of bathymetry and friction defined bilinearly per block: code \(2\)
    Argument \(0\) reads the file, and argument \(-1\) creates it. The next line specifies the name of the ASCII file containing the bathymetry and friction information. This file must be located in the exec directory. When creating the file (argument \(-1\)), it consists of 2 columns containing the \(x\) and \(y\) coordinates of the four vertices of each block of the master mesh. The user must then complete the file by adding two columns of reals giving, for each coordinate, the bathymetry and friction values.

2.2.6 Defining the boundary conditions: COND

The COND header is used to define the boundary conditions of the problem. Boundary conditions are defined by a number (written on one line) and, if applicable, real values (written on another line). The available boundary conditions are:

  • 0: free outflow condition (copied through)
  • 1: mirror condition
  • 2: Dirichlet condition on the primitive variables. The values of the \(n_{dof}\) primitive variables must then be defined on the next line. If the value \(10^{20}\) is used, the variable is considered free.
  • 3: user-defined condition. The user must then define the boundary condition function in the routine ~/CERF/sources/PHY/USER/fct_cond.f90. The next line defines the number of the user-defined function.
  • 4: Dirichlet condition on the conservative variables. The values of the \(n_{dof}\) conservative variables must then be defined on the next line. If the value \(10^{20}\) is used, the variable is considered free.
  • 999: No boundary condition. Fluxes are not computed.

The definition of the boundary conditions at the domain edges then depends on the type of master mesh used:

  • In the case of a “shock tube”: code \(0\)
    This is the case where the MAME section has code \(1\), argument \(0\), and the INIT section has code \(0\). In this case, no definition is necessary.
  • In the case of a “2D” mesh: code \(1\)
    This is the case where the MAME section has code \(1\), argument \(1\). The boundary conditions are then defined on the domain edges in the order \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\). For each edge, 1 or 2 lines are used to define the boundary condition.
  • In the case of a “3D” mesh: code \(2\)
    This is the case where the MAME section has code \(1\), argument \(2\). The boundary conditions are then defined on the domain edges in the order \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\), \(z_{min}\), \(z_{max}\). For each edge, 1 or 2 lines are used to define the boundary condition.
  • In the case of a “GMSH” mesh: code \(3\)
    This is the case where the MAME section has code \(2\). The “zone” numbers defined by GMSH are then used. The argument defines the number of zones to process. These zones correspond to the domain edges. For each zone, 1 or 2 lines are used to define the boundary condition.
TipExample boundary conditions 
COND    1    0
1
1
1
1

In this example, “mirror” conditions are applied on the 4 edges of a rectangular “2D” domain.

2.2.7 Defining the mesh: MESH

The MESH header is used to define the domain mesh, i.e. the discretization of the blocks defined in the MAME section. In addition, the mesh (de)refinement parameters are defined here. The default code is \(0\).

The following keywords can then be defined/modified:

  • NBDS: Number of domains to create, i.e. number of MPI processes (default value \(1.\))
  • MARL: Maximum refinement level (“MAximal Refinement Level”) (default value \(0.\))
  • COPA: Threshold value of the coarsening criterion (“mesh COarsening PArameter”) (default value \(0.002\))
  • REPA: Threshold value of the refinement criterion (“mesh REfinement PArameter”) (default value \(0.02\))
  • FDRA: Number of the user-defined function specifying the refinement to apply. This function is defined in the routine ~/CERF/sources/UTI/USER/fct_mesh.f90
  • NZRA: Number of zones defining the refinement to apply (default 1.). Followed, for each zone, by \(1\) integer and \(6\) reals defining the refinement level to apply to each block in the zone and the zone boundaries \(x_{min}\), \(x_{max}\), \(y_{min}\), \(y_{max}\), \(z_{min}\), \(z_{max}\).
Tip 2.2: Example of refinement by 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.

We return to the “dam-break” example Tip 2.2. In a “2D” domain of \(4 \times 3\) filled with air, we consider a column of water on the left of height \(2\) and width \(1\). The objective is to refine the mesh around the air-water interface. We therefore define 3 zones. The first zone broadly covers the entire domain and is assigned refinement level \(0\). The second covers the domain occupied by the water with a margin of \(0.25\), to which the maximum refinement level \(3\) is assigned. And finally, the third covers the domain occupied by the water with a margin of \(-0.25\), to which the minimum refinement level \(0\) is assigned, in order to minimize the number of cells. CERF will automatically (i.e. without user intervention) adjust the mesh level between levels \(0\) and \(3\) in order to satisfy the criteria imposed by the mesh generator. In addition, the domain is decomposed into 4 domains, and the mesh refinement criterion management parameters are modified Section 1.1.3.3.

2.2.8 Defining “obstacles”: OBST

The OBST header is used to define a set of cells to which a “rigid fluid” penalization is applied, naturally in the case where the two-fluid model is selected. The default code is \(0\), and the argument defines the number of obstacles to process.
For each obstacle, the following is written on one line: a file name, the obstacle density, and the penalization type.

  • file name: this is a character string (max 20 characters) defining the name of the ASCII file containing the mesh of the obstacle envelope, with triangular elements in .OBJ format. This file must be located in the exec directory.
  • obstacle density: this is a real number defining the density of the obstacle. This density must satisfy \(\rho_a \leq \rho_{obs} \leq \rho_w\).
  • penalization type: this is an integer defining the type of penalization. The available penalization types are:
    • -1: “fixed” type penalization. A zero velocity is imposed.
    • 0: “free” type penalization. The obstacle behaves as a free rigid solid.
    • >0: “imposed” type penalization. The obstacle behaves as a rigid solid for which the velocity of the center of gravity and the rotational velocity are imposed. The integer value defines the number of the user-defined function describing the motion in the routine ~/CERF/sources/PHY/USER/fct_mvsol.f90.
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

In this example, we define a cube-shaped obstacle with side length \(1\), centered at \((0.5,0.5,0.5)\). The vertices of the obstacle are defined, followed by its faces. Vertices are defined by the letter v followed by the vertex coordinates. Faces are defined by the letter f followed by the indices of the face’s vertices. The figure below illustrates the shape of the obstacle thus defined. Example of a cube described in obj format

2.2.9 Defining the numerical parameters: NUME

The NUME header is used to define the numerical parameters of the problem to be solved. The default code is \(0\).

The following keywords can then be defined/modified:

  • TINT: Computation time interval (Time INTerval) (default value \(0.\))
  • CCFL: CFL coefficient Important 1.1 (default value \(0.9\))
  • TDOR: Time discretization order (Time Discretization ORder) 1 or 2 (default value \(1.\))
  • SDOR: Space discretization order (Space Discretization ORder) 1 or 2 (default value \(1.\))
  • LIMI: Limiter type 0/Barth, 1/Cartesian (default value \(0.\))
  • NPRO: Number of probes < 10 (default value \(0.\)). Then, for each probe, one line containing 3 reals (coordinates \(x\), \(y\), \(z\) of the probe)
  • SAVE: Save type 0/No, 1/Yes. The units digit refers to saving in cerfbin-xxx files. The tens digit refers to saving in 1D gnuplot format. (default value \(01.\))

2.3 The CERF source files

2.3.1 Structure and modules

As illustrated in Figure 2.1, the CERF source code is organized into several directories:

  • ./sources/PHY contains all the lowest-level routines for handling physical variables and entities. The global physical variables and the data types (in the Fortran 90 sense), such as the degrees of freedom, their gradients, the fluxes, or the physical characteristics, are defined in the module phy_typ (./sources/PHY/mod_phy_typ.f90). The module phy (./sources/PHY/mod_phy.f90), in turn, contains the module phy_typ as well as all the interfaces of the routines contained in the PHY directory. During compilation, the compiled result of the routines in this directory is archived in the library ./lib/lib_PHY.a.
  • ./sources/GEO contains all the routines for handling geometric variables and entities: computing interface fluxes, computing source terms, etc. The global geometric variables and the data types (in the Fortran 90 sense), such as the list of faces, the list of cells, the mesh, etc., are defined in the module geo_typ (./sources/GEO/mod_geo_typ.f90). The module geo_typ contains the module phy. They are nested. The module geo (./sources/GEO/mod_geo.f90), in turn, contains the module geo_typ as well as all the interfaces of the routines contained in the GEO directory. During compilation, the compiled result of the routines in this directory is archived in the library ./lib/lib_GEO.a.
  • ./sources/NUM contains all the higher-level routines for handling numerical variables and entities: the rk2 algorithm, saving, MPI communication, etc. The global numerical variables and the data types (in the Fortran 90 sense), such as the “computation”, are defined in the module num_typ (./sources/NUM/mod_num_typ.f90). The module num_typ contains the module geo. They are nested. The module num (./sources/NUM/mod_num.f90), in turn, contains the module num_typ as well as all the interfaces of the routines contained in the NUM directory. During compilation, the compiled result of the routines in this directory is archived in the library ./lib/lib_NUM.a.
  • ./sources/UTI contains the programs and all the routines required for pre- and post-processing, and therefore in particular for managing the AMR mesh. The module uti (./sources/UTI/mod_uti.f90) contains the module num as well as all the interfaces of the routines contained in the UTI directory. During compilation, the compiled result of the routines in this directory is archived in the library ./lib/lib_UTI.a.

The modules phy, geo, num, and uti are nested and interdependent. The data types defined in them are the basic tools of the finite-volume method. As part of managing AMR meshes, it was necessary to develop new tools, which have been grouped into two modules.

  • zorder (./sources/UTI/mod_zorder.f90): this module contains the tools for managing the “z-order” data structure used to manage the AMR mesh. It contains all the routines required for handling Morton codes.
  • msh (./sources/UTI/mod_msh.f90): this module contains the tools for managing the “mesh” data structure used to manage the AMR mesh. It contains all the routines required for managing the AMR mesh. The data structures of the finite-volume code are stored in “fixed” arrays for performance reasons. Managing mesh graphs, on the other hand, is more complex and requires dynamic data structures with linked lists. The msh module contains all the tools required for managing these data structures.

2.3.2 Dependency graph of the main program

Below is the dependency graph of the main program cerf (excluding MPI routines and display routines). Routines depending on the phy module are outlined in green, routines depending on the geo module are outlined in blue, and routines depending on the num module are outlined in red. The HTML documentation provides direct access to a routine’s source code by clicking on its name in the graph 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: Dependency graph of the cerf routines

2.3.3 Dependency graph of the pre-processing program

Below is the dependency graph of the pre-processing program cerf_input (excluding MPI routines and display routines). Routines depending on the phy module are outlined in green, routines depending on the geo module are outlined in blue, routines depending on the num module are outlined in red, and routines depending on the uti module are outlined in purple. The HTML documentation provides direct access to a routine’s source code by clicking on its name in the graph 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: Dependency graph of the cerf_input routines

2.3.4 Dependency graph of the mesh-modification program

Below is the dependency graph of the mesh-modification program cerf_amr (excluding MPI routines and display routines). Routines depending on the phy module are outlined in green, routines depending on the geo module are outlined in blue, routines depending on the num module are outlined in red, and routines depending on the uti module are outlined in purple. The HTML documentation provides direct access to a routine’s source code by clicking on its name in the graph 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: Dependency graph of the cerf_amr routines