Subsections

# Domain: Horizontal Grid (mesh) (domhgr.F90 module)

## Coordinates and scale factors

The ocean mesh ( the position of all the scalar and vector points) is defined by the transformation that gives as a function of . The grid-points are located at integer or integer and a half values of as indicated in Table 4.1. The associated scale factors are defined using the analytical first derivative of the transformation (2.6). These definitions are done in two modules, domhgr.F90 and domzgr.F90, which provide the horizontal and vertical meshes, respectively. This section deals with the horizontal mesh parameters.

In a horizontal plane, the location of all the model grid points is defined from the analytical expressions of the longitude and latitude as a function of . The horizontal scale factors are calculated using (2.6). For example, when the longitude and latitude are function of a single value ( and , respectively) (geographical configuration of the mesh), the horizontal mesh definition reduces to define the wanted , , and their derivatives in the domhgr.F90 module. The model computes the grid-point positions and scale factors in the horizontal plane as follows:

 glamt gphit glamu gphiu glamv gphiv glamf gphif

 e1t e2t e1t e2t e1t e2t e1t e2t

where the last letter of each computational name indicates the grid point considered and is the earth radius (defined in phycst.F90 along with all universal constants). Note that the horizontal position of and scale factors at -points are exactly equal to those of -points, thus no specific arrays are defined at -points.

Note that the definition of the scale factors ( as the analytical first derivative of the transformation that gives as a function of ) is specific to the NEMO model [Marti et al., 1992]. As an example, is defined locally at a -point, whereas many other models on a C grid choose to define such a scale factor as the distance between the -points on each side of the -point. Relying on an analytical transformation has two advantages: firstly, there is no ambiguity in the scale factors appearing in the discrete equations, since they are first introduced in the continuous equations; secondly, analytical transformations encourage good practice by the definition of smoothly varying grids (rather than allowing the user to set arbitrary jumps in thickness between adjacent layers) [Tréguier et al., 1996]. An example of the effect of such a choice is shown in Fig. 4.4.

## Choice of horizontal grid

The user has three options available in defining a horizontal grid, which involve the namelist variable jphgr_mesh of the namcfg namelist.

jphgr_mesh=0
The most general curvilinear orthogonal grids. The coordinates and their first derivatives with respect to and are provided in a input file (coordinates.nc ), read in hgr_read subroutine of the domhgr module.
jphgr_mesh=1 to 5
A few simple analytical grids are provided (see below). For other analytical grids, the domhgr.F90 module must be modified by the user.

There are two simple cases of geographical grids on the sphere. With jphgr_mesh=1, the grid (expressed in degrees) is regular in space, with grid sizes specified by parameters ppe1_deg and ppe2_deg, respectively. Such a geographical grid can be very anisotropic at high latitudes because of the convergence of meridians (the zonal scale factors become much smaller than the meridional scale factors ). The Mercator grid (jphgr_mesh=4) avoids this anisotropy by refining the meridional scale factors in the same way as the zonal ones. In this case, meridional scale factors and latitudes are calculated analytically using the formulae appropriate for a Mercator projection, based on ppe1_deg which is a reference grid spacing at the equator (this applies even when the geographical equator is situated outside the model domain). In these two cases (jphgr_mesh=1 or 4), the grid position is defined by the longitude and latitude of the south-westernmost point (ppglamt0 and ppgphi0). Note that for the Mercator grid the user need only provide an approximate starting latitude: the real latitude will be recalculated analytically, in order to ensure that the equator corresponds to line passing through - and -points.

Rectangular grids ignoring the spherical geometry are defined with jphgr_mesh = 2, 3, 5. The domain is either an -plane (jphgr_mesh = 2, Coriolis factor is constant) or a beta-plane (jphgr_mesh = 3, the Coriolis factor is linear in the -direction). The grid size is uniform in meter in each direction, and given by the parameters ppe1_m and ppe2_m respectively. The zonal grid coordinate (glam arrays) is in kilometers, starting at zero with the first -point. The meridional coordinate (gphi. arrays) is in kilometers, and the second -point corresponds to coordinate . The input variable ppglam0 is ignored. ppgphi0 is used to set the reference latitude for computation of the Coriolis parameter. In the case of the beta plane, ppgphi0 corresponds to the center of the domain. Finally, the special case jphgr_mesh=5 corresponds to a beta plane in a rotated domain for the GYRE configuration, representing a classical mid-latitude double gyre system. The rotation allows us to maximize the jet length relative to the gyre areas (and the number of grid points).

The choice of the grid must be consistent with the boundary conditions specified by jperio, a parameter found in namcfg namelist (see §8).

## Output Grid files

All the arrays relating to a particular ocean model configuration (grid-point position, scale factors, masks) can be saved in files if (namelist variable in namdom). This can be particularly useful for plots and off-line diagnostics. In some cases, the user may choose to make a local modification of a scale factor in the code. This is the case in global configurations when restricting the width of a specific strait (usually a one-grid-point strait that happens to be too wide due to insufficient model resolution). An example is Gibraltar Strait in the ORCA2 configuration. When such modifications are done, the output grid written when is no more equal to the input grid.

Gurvan Madec and the NEMO Team
NEMO European Consortium2017-02-17