C. Details of the Mesh and the FieldVar Classes

Figure C.1: A domain and its boundary halo.

R8cm

This chapter explains some of the terms commonly used in meshes. There are no standardized definitions for these terms, so we define a few here.

Fig. C.1 shows a domain D in black of length Lx x Ly . It is divided into Nx x Ny cells. We will define fields (variables) on this discretized domain. The lower left corner of the domain corresponds to the origin of a coordinate system. The grid-cell size $\Delta$x x $\Delta$y is Lx/Nx x Ly/Ny .

Certain variables are stored at the center of cells and have a Mesh Collocation Type of Cell-centered; the blue circle shows a position where a cell-centered variable will be stored. However one may store variables at other places too e.g. a horizontal velocity stored on a face which has its face-normal in the horizontal direction. Such a variable is said to have a FaceCenteredX mesh collocation type. Other mesh collocation types are FaceCenteredY, FaceCenteredZ and VertexCentered, where the variables are stored at cell corners. Fig. C.2 shows these positions clearly.

Figure C.2: Locations of variables. The black dot is the position where CellCentered variables are collocated, the blue dots are FaceCenteredX, the red one FaceCenteredY and the green ones FaceCenteredZ. The corners of the cube store VertexCentered variables.

Sometimes one may need to keep a halo of cells outside the domain D to help implement boundary conditions. The width of the boundary halo of cells, b , may be anything; it does not have to be equal to the width of any finite-difference/finite-volume stencil that you might be using. It might even be 0, for example, when implementing Dirichlet boundary conditions using second-order central difference. Fig. C.1 shows a boundary halo, 1 cell wide, in red.

Variables defined on the discretized domain are kept in arrays. However, when operating on arrays, it is frequently crucial to know the spatial locations of the domain where the variables are kept. The rectangular region is space, whose field variables are stored in an array V, is called the patch associated with the array V.

A patch of cells is defined by the lower and upper bounding box corners in integer cell coordinates. Patches are non-overlapping and completely cover the domain. The locations of these corners are described using an integer index stored in vectors firstIndices[2] and lastIndices[2]. These are 3 long for 3D meshes. For Fig. C.1, point A is the lower bounding box corner and has indices {-1, -1}; point B has indices {Nx + 1, Ny + 1}. However, note that the spatial location of A is (- $\Delta$x, - $\Delta$y) and B is (Lx + $\Delta$x, Ly + $\Delta$y) .

However, the patch is an abstract concept and is rarely used. A more useful (and practical) concept is the Region. This is a consequence of parallel computing and the necessity of applying various types of boundary conditions. Consider Fig. C.4 which shows the situation in a domain-decomposed parallel computing paradigm. Subdomain S2 is shown with a red boundary halo (of width 1) and green ghost-cell halo of width 2. Generally, these widths are different - the ghost-cells halo width is determined by the width of spatial discretization stencils while the bounday halo width is determined by the boundary condition treatment. This is clearly seen in Fig. C.1, where the cell-centered variable in boundary halo interacts directly with the cell immediately inside the domain. On the other hand, in Fig. C.4, the discretization stencil has a radius of 2. These are specified separately when setting up the mesh. The ghost-cell halo is updated using MPI. The bounding box corners now play an important part in identifying the spatial location of an array. In Fig. C.4, F denotes the lower bounding box corner and has indices {1, -1} and spatial locations ($\Delta$x, - $\Delta$y) . The locations of all other points can be calculated with respect to F. The union of the patch (black cells in Fig. C.4), the ghost halo (green cells in Fig. C.4) and the boundary cells (red cells in the same figure) constitute the Region.

Variables are defined on Regions, not patches. A Region has a position in space, defined by its lowerCorner and upperCorner, as shown in Fig. C.3.. A real variable spread on a Region is stored as a 1-D double-precision array sized to account for the collocation type, boundary conditions, and stencils. The FieldVar interface provides access to the Regions and their corresponding data arrays. The each axis of a data array is as large or larger than the corresponding dimension in the Region (this is explained further in the next paragraph). The bounds of the data array are stored in vectors lowerCorner[2] and upperCorner[2]. These are 3 long for 3D meshes.

Figure C.3: A region showing the indexing of cells (and data arrays).

Consider a cell-centered variable C and a FaceCenteredX variable U defined on the patch in red Fig. C.1. Note that the dimensions of the arrays (in our terminology, their shape) containing the two variables are C[Nx+2][Ny+2] and U[Nx+3][Ny+2]. Whenever one operates on a variable (stored in an array), one also fetches the shape of the array, though one can calculate these based on the shape of the Region and the collocation type of the variable. However, it is a good programming practive to also fetch the corners of the Region and check whether the size of the Region and that of the array are consistent.

Figure C.4: Above: The domain D divided into 2 subdomains S1 and S2 along the thick green line. Below: The subdomain S2 , showing the boundary halo in red and the ghost cells in green.