Following the successful discussion that we had a few year's ago on conventions for storing unstructured grid data in netCDF files which eventually led to the UGRID conventions, I would like to propose a simple convention for documenting staggered data on structured grids that is consistent with the UGRID conventions. My proposal, which I will refer to as SGRID convention, is described below.

The link http://bit.ly/1ELq2hh points to this page.

Introduction

The CF-conventions are widely used for storing and distributing environmental / earth sciences / climate data. The CF-conventions use a data perspective: every data value points to the latitude and longitude at which that value has been defined; the combination of latitude and longitude bounds and cell methods attributes can be used to define spatially averaged rather than point values. This is all great for the distribution of (interpolated) data for general visualization and spatial data processing, but it doesn't capture the relationship of the variables as computed by a numerical model (such as Arakawa staggering). Many models use staggered grids (using finite differences, or finite volume approach) or use a finite element approach of which the correct meaning may not be captured easily by simple cell methods descriptors. This becomes a problem if you don't want to just look at the big picture of the model results, but also at the details at the grid resolution e.g. what is the exact meaning of a flux on the output file in discrete terms? Can we verify the mass balance? Can the data be used for restarting the model? Correctly handling the staggered data has always been a crucial element of the Delft3D post-processing tools. In the UGRID conventions, we have defined the (unstructured) grid as a separate entity on the file which consists of nodes and connections of nodes defining edges, faces, and volumes. For a structured (staggered) grid we are currently lacking a consistent convention. Although one could store structured grid data using UGRID conventions, some fundamental aspects such as distinction between grid directions would be lost. In this context I propose the lightweight SGRID conventions to define the core aspects of a structured staggered grid without trying to capture the details of finite element formulations. This proposal serves merely the purpose of getting the conventions for structured grids on par with those for unstructured grids.

Proposal

Consistent with the UGRID conventions we use the following terms for points, lines, and cells that make up a grid.

In the UGRID conventions the focus is on describing the topology of the mesh (connectivity of the nodes, edges, faces, and volumes as appropriate). The topology of a structured grid is inherently defined; the focus for the SGRID conventions is therefore on the numbering used. Still we need to distinguish between 2D and 3D grids (1D conventions may be defined consistently).

2D grid

where the padding type may be one of the four literal strings: "none", "low", "high", or "both" depending on whether the face_dimension is one shorter than the corresponding node_dimension (padding:none), one longer than the corresponding node_dimension (padding:both), or of equal length with one extra value stored on the low or high end of the dimension. The edge1_dimensions and edge2_dimensions attributes may be used to define separate dimensions for the edges (see the ROMS example below), but by default the edge dimensions are assumed to be consistent with the dimensions used by the edges and faces respectively. The optional vertical_dimensions attribute may be used to specify the names of the dimensions for the layers and layer interfaces respectively using the same syntax: layer_dimension:layer_interface_dimension (padding:type).

Note: The numbering of the edges corresponds to the order of the dimensions in the dimensions attributes. The order of the dimensions listed here does not change since these are specified as a string. The actual order of dimensions in the netCDF API (and hence in the dump generated by different tools) depends on the programming language used. Hence, the order of the dimensions listed here may differ from the order of the dimensions in the data definition.

3d grid

Note: The edge1, edge2, and edge3 are in a 3D grid aligned to the dimensions1, 2, and 3 respectively, whereas the edge1 and edge2 are in a 2D grid perpendicular to the dimensions 1 and 2 respectively. The face1, face2, and face3 play that role in the 3D grid.

Examples

Delft3D

S1(time, MMAX, NMAX)
U1(time, MMAX, NMAX)
V1(time, MMAX, NMAX)

The edge_dimension attributes are not needed.

ROMS

ZETA(time, eta_rho, xi_rho)
U1(time, eta_u, xi_u)
V1(time, eta_v, xi_v)

Need for the edge_dimension attributes.

WRF?

Some example for another type of structured grid?