Scalar coordinate variables (height)

[jesusff]

Hi,

we just had some doubts during an FPS-URB-RCC meeting regarding the dimensions and coordinates in the CORDEX output files. The example in the archive specifications (Section 13) is for precipitation, which has no height coordinate. And the example on vertical coordinates (Section 13.3) refers to a proper coordinate variable (soil depth) with dimension 4.

After discussions with @cofinoa, things became clear on how to proceed with the coordinates attribute for a variable, which is also quite clear in the CF conventions. Only scalar and auxiliary coordinates are mandatory to be listed in the coordinates attribute.

However, I couldn't find a place (@larsbuntemeyer @gnikulin ?) where it is stated whether in CORDEX we should degenerate the height dimension and have it as a scalar coordinate variable. E.g:

variables:
	double height ;
		height:units = "m" ;
		height:axis = "Z" ;
		height:positive = "up" ;
		height:long_name = "height" ;
		height:standard_name = "height" ;
	float tas(time, rlat, rlon) ;
                [...]
		tas:coordinates = "height lat lon" ;

This seems to be the CMOR behaviour. Alternatively, height could be a proper coordinate variable, with an associated dimension of 1:

dimensions:
        height = 1;
        [...]
variables:
	double height(height);
		height:units = "m" ;
		height:axis = "Z" ;
		height:positive = "up" ;
		height:long_name = "height" ;
		height:standard_name = "height" ;
	float tas(time, height, rlat, rlon) ;
                [...]
		tas:coordinates = "lat lon" ;

Another misleading point was on the dimensions column in the CORDEX-CMIP6/data-request.csv, which for tas has dimensions = longitude latitude time height2m, which led us (@LluisFB) to think of them as the coordinate names we should use. However, these names are just used as keys in the CMOR tables, and the CMOR library then assigns the out_name height to the variable in the output file.

In summary, we still cannot infer from the CMOR tables whether we should degenerate the height dimension to a scalar coordinate variable, can we?

[larsbuntemeyer]

However, I couldn't find a place where it is stated whether in CORDEX we should degenerate the height dimension and have it as a scalar coordinate variable.

Yes, i think we did not explicitly state this, so i think it falls back to CF conventions which seems to let you choose from both possibilities. From experience, i would say that most ESGF datasets probably use scalar coordinates from what i have seen.

Another misleading point was on the dimensions column in the CORDEX-CMIP6/data-request.csv, which for tas has dimensions = longitude latitude time height2m, which led us (@LluisFB) to think of them as the coordinate names we should use. However, these names are just used as keys in the CMOR tables, and the CMOR library then assigns the out_name height to the variable in the output file.

Yes, that's confusing but right! It's important to distinguish between the table keys and out_name which are in most cases the same but not always. For example, you can have the same out_name (e.g., height with values 2 and 10) but would need the key to be unique so they can appear both, e.g., in the coordinates table as height2m, height10m. After all, the data-request.csv table in the current form is mostly the cmor tables in csv format...

[larsbuntemeyer]

this should be update as an example in the archive specs