Meshes

Mesh files

FESOM2 as well as FESOM1.4 is formulated on general triangular meshes. There are three mesh files that are read: nod2d.out, elem2d.out and aux3d.out. Those three files are enough to define a mesh. The files are written as simple ASCII files storing the information on the coordinates of mesh vertices, on how vertices are combined in triangles and on bottom depth at vertices. The format of the files is as follows:

nod2d.out

$V$
$v$	$x_1$	$y_1$	$i_1$
…	…	…	…
$V$	$x_V$	$y_V$	$i_V$

Here $V$ is the number of surface vertices, $x_v$ and $y_v$ are the longitude and latitude (in angular measure) of vertex $v$, and $i_v$ the index of vertex $v$. This field is obsolete and is kept for mesh compatibility with FESOM1.4.

elem2d.out

$C$
$v_{11}$	$v_{12}$	$v_{13}$
…	…	…
$v_{C1}$	$v_{C2}$	$v_{C3}$

Here $C$ is the number of triangles, $v_{c1}$, $v_{c2}$, $v_{c3}$ are the vertices of triangle (cell) $c$. The indexes and coordinates of vertices are provided in the nod2d file ($v$).

aux3d.out (to be renamed to depth.out)

$L$

$h_{1}$

…

$h_{l}$

…

$h_{L}$

$H_{1}$

…

$H_{v}$

…

$H_{V}$

Here $L$ is the number of model levels (e.g. sstandard is 48), $h_{l}$ is the depth of each model level and $H_{v}$ is the depth at each vertex defined in nod2d.out file.

Those three files are read during the mesh partitioning and several additional files are generated by the partitioner in the folder where the mesh files are located.

Mesh arrays

The nod2d.out, elem2d.out and aux3s.out files are read in variables and arrays with names inherited from FESOM1.4 where vertices were dubbed nodes and cells elements. Full files are only read on mesh partitioning step. Local copies are saved for each PE and read in production runs.

Name correspondence

$V\,\to {\tt nod2D}$
$C\,\to {\tt elem2D}$
The array coord_nod2D(1:2,1:myDim_nod2D+eDim_nod2D) stores vertex coordinates in radian measure.``1:myDim_nod2D`` are the vertices that belong to my PE (myPE), and myDim_nod2D+1:myDim_nod2D+eDim_nod2D are the halo vertices. The halo vertices share a common triangle with vertices that belong to myPE, yet do not belong to the myPE themselves.
Each column of array elem2D_nodes(1:3,1:myDim_elem2D+eDim_elem2D+eXDim_elem2D) stores vertex indices of particular triangle. 1:myDim_elem2D are the triangles that belong to myPE, which are those that contain at least one vertex that belongs to myPE. Thus, triangles with vertices that belong to several PE are counted as my triangle by each PE. The rest combines two types of halo: First triangles sharing an edge with my triangles are added, and then triangles that share vertex with my triangles, but are absent in the smaller halo.
Local numbering is used on each PE. Additional arrays are available to do local to global transform if needed.

Auxiliary mesh arrays

Edge arrays:

$E\,\to$ {\tt edge2D}$
edge(1:2, myDim_edge2D+eDim_edge2D) is the array storing vertices of an edge (its columns are the code analog of the set $V(e)$)
edge_tri(1:2, myDim_edge2D+eDim_edge2D) is the array storing triangles on the left and right of the edge (its columns correspond to $C(e)$).
elem2D_edges(1:3, 1:myDim_elem2D) stores edges of triangles. It columns correspond to $E(c)$
edge_dxdy(2,myDim_edge2D+eDim_edge2D) stores $\mathbf{l}_e$ in radian measure.
edge_cross_dxdy(4,myDim_edge2D+eDim_edge2D) stores two cross-edge ${\bf d}_{ec}$ vectors in physical measure (meters).

Neighborhood arrays:

Two arrays nod_in_elem2D_num, nod_in_elem2D store the number of cell neighbors and their indices for vertex $v$ (correspond to $C(v)$)
Two arrays nod_neighbr_num, nod_neighbr store the number of vertex neighbors and their indices for vertex $v$ (correspond to $V(v)$)

Areas and derivatives:

elem_area(1:myDim_elem2D+eDim_elem2D+eXDim_elem2D) stores areas of elements computed using local flat metrics on elements.
areas(1:K,1:myDim_nod2D+eDim_nod2D) are the horizontal areas of scalar control volumes. They are computed combining contributions from triangles.

Modularity

All arrays related to mesh are packed in a structure of derived type mesh, which is passed as an argument to routines using mesh arrays (nearly all routines). In order to keep the array names in subroutines compatible with the old FESOM names (the names listed above), there are pointer associations between the fields of the structure and the names used above. Coding can rely on old names. The same logics is pursued with all other derived data types. This also reflects history of code development. The code was initially using global arrays, which prevented modularity.

\(V\)
\(v\)	\(x_1\)	\(y_1\)	\(i_1\)
…	…	…	…
\(V\)	\(x_V\)	\(y_V\)	\(i_V\)

\(C\)
\(v_{11}\)	\(v_{12}\)	\(v_{13}\)
…	…	…
\(v_{C1}\)	\(v_{C2}\)	\(v_{C3}\)