Modified SLEVE parametric vertical coordinate

[taylor13]

Question

I received a question regarding how in CF one should store data stored on a "modified" SLEVE parametric coordinate. It has apparently been modified by checking whether layers become thinner than a critical depth (leading to numerical instabilities). It doesn't appear that the algorithm that adjusts the layers is easily described. This leads to the following question:

Consider 3-d data stored on N levels in the atmosphere, but with the heights of these levels varying with horizontal position. The heights of the levels cannot be (easily) represented by a parametric formula. What is the CF-compliant way to store this data? Presumably, the height coordinate must be recorded: H(x,y,k), where k is the vertical index. But how is that related to the variable of interest which is also a function of (x,y,k).

[pvanlaake]

The simple answer is: use an ancillary variable. The parametric vertical coordinates are then stored as a regular data variable and the scientific variable of interest has an ancillary_variables attribute pointing to the parametric vertical coordinates.

The problem arises from identifying the ancillary variable as vertical coordinates. In the standard case, the scientific variable has a standard_name attribute that identifies it as one of nine defined parametric formulations and an additional formula_terms attribute giving the arguments to the algorithm to compute the parametric coordinates. There is no alternative way to communicate that an ancillary variable should be used instead, insofar as I am aware.

Perhaps this is something that should be added to the conventions? There is a corollary in the form of the latitude and longitude coordinates of a horizontal grid that was not defined as a Cartesian product of latitude and longitude: supply a grid mapping variable or include two-dimensional grids for latitude and longitude coordinates.

I have also come across a variant of "atmosphere_hybrid_sigma_pressure_coordinate", whereby top and bottom coordinates are specified, rather than the CF-standard mid-point possibly with boundary coordinates. This would also benefit from a including an ancillary variable rather than the formulaic representation.

[davidhassell]

The grid cell heights should be stored as a 3-d auxiliary coordinate variable, referenced by the data variable's coordinates attributes.
Cheers,
David

[taylor13]

So we've had two options suggested: store as a variable pointed to either by an ancillary_variables attribute or by a coordinates attribute. I would think that the coordinates attribute option is preferred. Anyone disagree?

[taylor13]

another thing I wonder about.... should be "zfull_bnds(lev, bnds, i)" instead of "zfull_bnds(lev, i, bnds)"? @davidhassell ? I think probably either way is o.k., and we haven't said anything about this in CMIP7.

[sol1105]

The int i(i) index comes from how CMOR/CMOR tables describe the index dimensions for unstructured grids. For CMIP7 we plan to provide some data on the ICON grid (which is triangular and thus unstructured) and some also regridded on a regular lat-lon grid.

int i(i) ;
i:units = "1" ;
i:long_name = "cell index along first dimension" ;

[taylor13]

Nice ... use my own documents to correct me. :-). Thanks!
And indeed, it is o.k. to define a simple integer coordinate this way; we also do it for vertical levels, I think.

[davidhassell]

Hi - I think the CDL only needs this for the zfull variable:

	double zfull(lev, i);
		zfull:bounds = "zfull_bnds" ;
		zfull:standard_name = "height_above_reference_ellipsoid" ;
		zfull:long_name = "Altitude of Model Full-Levels" ;
		zfull:units = "m" ;

since of the other attributes are standarised on auxiliary coordinate variables.

[taylor13]

I wondered about that. Typically for the atmosphere you want the pressure thickness of layers (for conservative vertical integration of quantities) or, equivalently, you need the product density*delta-z (mean density in layer times the depth of the layer). To vertically integrate for this version of the SLEVE coordinate, you would separately need to store 3-D density and either 3-D layer thickness or 3-D zfull_bnds (as in the above sample output). To save space, you could put those in a separate file. Another option would be to store the pressure field on each zfull_bnds level.

I think in CMIP (at least in earlier phases), we asked those reporting their model output on height coordinates to also report the pressure for half and full z-levels.

[pvanlaake]

This still does not overcome the issue that I raised in my earlier post: the conventions do not have a mechanism to convey that this arrangement represents a (realized) parametric vertical coordinate. Reading the CDL that @sol1105 posted it is easy enough to "reason" the relationships between the scientific variable var and its multi-dimensional vertical coordinate zfull but there is no convention about this. I doubt that a generic CF software tool will be able to make the connection.

[sol1105]

The data will be published via ESGF as part of the CMIP7 assessment fast track, probably before the end of the year. Anything more sophisticated than the approach discussed here so far and summarized in my post above is probably not possible on that timeline. If there will be a new convention in time for our data publication, however, we will make sure to follow it.