Pressure or height as generic alevel coordinate

[wachsylon]

Hi,
if a model writes 3d output on pressure levels as model levels, what is the CMORization approach?
As far as I know: There is no general "plevs" or "alt"/"height" axis in the tables. Are those missing?
Best,
Fabi

[taylor13]

I am not aware of a model that uses actual pressure or actual altitude as the vertical coordinate, so strictly speaking model level data should not be written as a function of pressure or altitude. But suppose a modeling group wants to report (interpolate) their "model level" output as a function of pressure or altitude, how could they do this via CMOR?

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.

Neither of the above is a very elegant solution (and seems wasteful since they require storing a surface field (2d) along with the 3d data, even though the surface field is constant).

We could contemplate modifying CMOR (or the tables) to provide a nicer solution, but it would be helpful to understand why CMOR needs to store non-model-level data, when model-level data has been requested.

[wachsylon]

ICON/MPI-ESM2 will use a modified SLEVE coordinate. It will be hard to fully describe it in each CMIP conform file. I could try to find out what the formula is for this special SLEVE coordinate but I am not even sure if the modelers are willing to publish this information.
The experiment conductor themselves may have no idea how the SLEVE coordinate is constructed or described and therefore will configure ICON not correctly.

From a post-processing view, describing parametric vertical axes can be a bottleneck. The raw model output often needs to be merged to get the required auxiliary variable. And this variable has to have the same aggregation which requires that the model raw output is configured correctly before the standardization. Which, in turn, is not on the watch list of the experiment conductor..

Therefore, we probably would have troubles with standardizing the files.

It is also possible to write out ICON fields on pressure or height levels without post-processing. I am not sure if it is of great scientific value to have the data on a modified hybrid height axis. But if so, I will of course try to enable the submission by finding out the formula.

[taylor13]

Hi Fabi,

I guess there is some scientific judgement to be made here. I think many of variables that are requested on model levels are needed for one of the following purposes:

1. keeping better track of budgets of energy, radiation, water, chemical species, etc. (and the vertical fluxes from one model layer to the next)
2. reporting cloud properties -- interpolation of clouds often impairs inference due to its modification of the cloud overlap properties.
3. driving regional climate models.

Vertical interpolation will often preclude analysis. On the other hand, if these fields are also time-averaged, then exact budgets usually can't be computed anyway, so it may be that the interpolation of the data to pressure levels will not degrade its utility much more than time averaging does (although I really don't know if this is true). Do you know which variables are under consideration for reporting on pressure rather than model levels, and if the scientists involved think the output will still be useful?

You probably are already aware of this, but CF provides for a SLEVE coordinate here:
https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#_atmosphere_smooth_level_vertical_sleve_coordinate

If there is a modified form of the SLEVE, we would need to add it to the convention. Please let me know.

thanks,
Karl