SLEVE again

[wachsylon]

Hi,

now that there is a working plan by @sol1105 , we want to produce output that is conform to this with CMOR so that we can publish it in ESGF.

However, I cannot imagine how to so with CMOR at the moment. I tried with modifying a hybrid coordinate definition in the CMOR tables, but it fails because a zfactor zfull is depending on a vertical axis (lev) which i have afaik no option to register in CMOR before the other.

Do you have any guidance or suggestion how to realize that?

Best and thanks,
Fabi

[wachsylon]

i think what is needed is the same mechanism as for a unstructured grid (cmor_grid()) : a index variable plus the actual vertical axis variable. one difference is that this vertical axis variable is also depending horizontally.

[taylor13]

I'm just starting to look at this again, and it looks to me like this is going to require quite some effort to accommodate by CMOR (and current resources might not be able to support such work). Isn't it true that those analyzing the data will have to include special coding for this case? Do you think they will be willing to do that, or will they simply elect to exclude the model?

I think a better approach would be to simply interpolate the model data to a set of depths that were independent of longitude and latitude. Users would then be able to handle the data quite simply. The vertical interpolation could be done in a way that certain integral properties (e.g., ensuring conservation of mass) were preserved. I think the data would be much more frequently analyzed if it were simplified in this way.

Do those providing the data agree?

[wachsylon]

Isn't it true that those analyzing the data will have to include special coding for this case?

likely.

I think a better approach would be to simply interpolate the model data to a set of depths that were independent of longitude and latitude.

The problem with this approach was that there is no standard alevel axis for this. neither alt or plev. would you allow to add that?
Using a hybrid axis that exist in the standard has other potential downsides, especially a lot of pre-preparation work.

[sol1105]

@taylor13 Thanks for your quick reply. This may be a better solution than trying to implement workarounds with CMOR and cdo cmor, but: it is then no longer the native vertical grid, as requested.

I thus have the following question regarding the EMD: which vertical grid should then be registered? The EMD does only support native vertical grids, but if we then provide the data on a set of fixed height or pressure levels when it is expected/requested on the native grid, that can cause confusion as well? Would it be sufficient to add a descriptive text to the EMD vertical computational grid registration, eg. "Before publication the data will be interpolated to a set of fixed pressure levels: 1000hPa, 950hPa, ...."?

Lastly, the CMIP7 coordinates table does not include a generic "plev" or "alt" coordinate, so these would either have to be added, or we would have to "cheat" a fixed pressure axis into a generic hybrid sigma pressure / hybrid height definition as you depicted here:

One option for pressure would be to use the sigma coordinate with surface pressure reported everywhere as 1.e5 hPa and top of atmosphere pressure reported as 0. The sigma values would then be equal to 1.e-5 * pressure at that level.
One could similarly adapt the atmosphere hybrid height coordinate to store data as a function of altitude/height.

[taylor13]

(@davidhassell may be better able to provide suggestions here.)

Thanks for pointing out some of the earlier references to this issue, which I'd forgotten about. Regarding first, "how to store the data": If it's o.k. to interpolate the data, then I think I'd favor adding to the CMIP7 cmor coordinates table a general "alt" coordinate variable, for which the data provider can choose a set of appropriate altitudes to report. The coordinate table entry would look something like:

"axis_entry": {
    "alt": {
        "axis": "Z",
        "bounds_values": "",
        "climatology": "",
        "formula": "",
        "generic_level_name": "",
        "long_name": "Altitude",
        "must_have_bounds": "yes",
        "out_name": "alt",
        "positive": "up",
        "requested": "",
        "requested_bounds": "",
        "standard_name": "altitude",
        "stored_direction": "increasing",
        "tolerance": "1",
        "type": "double",
        "units": "m",
        "valid_max": "",
        "valid_min": "",
        "value": "",
        "z_bounds_factors": "",
        "z_factors": ""

For SLEVE-like coordinates, altitude seems like a good choice because the levels become nearly horizontal at high altitude. On the other hand, most models will report data that is most easily converted to pressure (using formula terms), so if you want to compare a SLEVE model's output to other models, then perhaps reporting it on constant pressure levels would be better. In that case we could define a generic "plev" coordinate.

You could also consider interpolating the SLEVE data to another parametric coordinate (e.g., hybrid sigma). The CMOR tables would allow you to write that data.

Now regarding the first question: What to document in the EMD? I don't think it is particularly critical how this is done since the information isn't used for any purpose other than to provide users with some idea about model vertical resolution. (The definitive information regarding the vertical grid is in the files themselves.). For the EMD, I would work with the options available on the registration form and choose as the vertical grid "atmosphere-sleve-coordinate" and then qualify that in the "description" section saying something about how it differs from the standard sleve coordinate. The number of layers and resolution questions can be answered as with any other grid. You could also include in "description" that "to facilitate analysis, you have interpolated model level data in the vertical, reporting it on constant altitude levels (or constant pressure levels)." You might even indicate how many levels.

Just some ideas .... maybe others have better suggestions.

[taylor13]

Upon further reflection, it may not be acceptable to interpolate in the vertical, for example, if producing output meant as input for dynamical downscaling (such as CORDEX). So, rather than defining "plev" or "alt" as unconstrained options for reporting on pressure levels or altitudes, we could define an index coordinate "lev" on which model data could be stored. The pressures could then be reported as a function of latitude longitude level and time as a separate variable (which we would need to add to the data request for models choosing to do this). Both "pfull" and "phalf" are defined in the data request, so these variables could record the model level pressures.

[davidhassell]

Hi,

For EMD, the vertical_coordinate type comes from a CV, and if there's a possibility not in that CV, then we must add it - there is no scope for setting an almost-right value and saying how we differ from it. This is no problem - we always envisaged expanding the EMD CVs as use cases arose.

The vertical grid in EMD is unequivocally the computational grid, and there should be no mention of the archive/analysis grid in the EMD (this is also the case for horizontal grids).

Cheers,
David

[sol1105]

@davidhassell @taylor13 Thanks for your replies

So, rather than defining "plev" or "alt" as unconstrained options for reporting on pressure levels or altitudes, we could define an index coordinate "lev" on which model data could be stored.

There is this deprecated CF feature about dimensionless vertical coordinates that could back a lev index-coordinate:
https://cfconventions.org/Data/cf-conventions/cf-conventions-1.13/cf-conventions.html#dimensionless-vertical-coordinate

The pressures could then be reported as a function of latitude longitude level and time as a separate variable (which we would need to add to the data request for models choosing to do this). Both "pfull" and "phalf" are defined in the data request, so these variables could record the model level pressures.

We would report zfull (fx) as the height of all levels is a time-invariant 3D field.

pfull and phalf would be time-dependent. Should these variables then be published for each frequency (and time cell_methods) that alevel variables are reported on? Or would you consider zfull to be sufficient?

The vertical grid in EMD is unequivocally the computational grid, and there should be no mention of the archive/analysis grid in the EMD (this is also the case for horizontal grids).

That makes sense, and since there is no vertical pendant of a horizontal grid_cells registered as output grid, the EMD will be fully agnostic of whatever we put in place eventually to report the alevel variables on.

expanding the EMD CVs

three_dimensional_time_invariant_height_levels or fixed_height_levels or what would be a good CV entry for this case?

[davidhassell]

Hi,

I'm a bit confused as what lev is, but there is a model_level_number standard name that can be used on a coordinate.

I'm not sure if we need a new EMD CV entry for this - the existing height ("Height is the vertical distance above the earth’s surface") seems like a good fit, in the absence of a defined parameterised CRS.

[taylor13]

Regarding theunitsattribute for lev, I think I would just set them units = "1"

Fitting this coordinate into CF seems like a cludge one way or the other. I wonder if @davidhassell or anyone else has thoughts about the following off-the-wall suggestion:

I had not realized that the heights were time-invariant. This means that if you included the heights in the file you would only increase its size by 1/N (where N is the number of time-slices saved). So the question is "could we define a new parametric vertical coordinate?" along the following lines:

---

Atmosphere modified smooth level vertical (SLEVE) coordinate

standard_name = "atmosphere_modified_sleve_coordinate"

Definition
z(k,j,i) = sigma(k)*zsleve(k,j,i)
where z(k,j,i) is the time-invarient height above the datum (e.g. the geoid, which is approximately mean sea level) at gridpoint (k,j,i), zsleve(k,j,i) is the local height of a model level divided by sigma(k), and sigma(k) is the dimensionless vertical coordinate calculated from the global mean value of z(k,j,i) at each level k divided by the global mean of z(K,j,i), the height of the top level (K).

The format for the formula_terms attribute is
formula_terms = "zsleve: var1"

No standard_name has been defined for zsleve.

---

The above definition relies on a dimensionless vertical coordinate, sigma(k), which would vary from 0 at sea level to 1 at the top of the model atmosphere.
Among current parametric coordinates, it would be unique in having a parameter that depends not only on i and j, but also on k. CF doesn't seem to forbid that though.

[davidhassell]

Hi Karl - Yes - we could put this definition into the EMD CVs, and if the archived data does not contain the as-yet-non-CF formula_terms then we're all good. We should get the new formula_terms into CF as well, of course!

[durack1]

Hi folks, this is duplicating information that was moved to a discussion #917 - would it be useful to move this back across again? This is not a CMOR issue, it's how to generate data using CMOR.

Just trying to work through standing issues, and this doesn't appear to be one

[sol1105]

@durack1 Yes it can be turned into a discussion again, thanks. If eventually it turns out that it requires a slight CMOR modification after all, it can be turned back into an issue or a new issue can be opened.

@taylor13 @davidhassell Thank you for your suggestions, we will try to write output with CMOR in that way and report how it worked out. Due to conferences/workshops this may take 2-3 weeks.