Add suffix to indicate a 3D field has an additional point above the model top

[ss421]

As part of the JEDI processing system, some of the Met Office operators use a vertical grid where there is an extra point added to include a point just above the model top (a full grid cell above the centre of the previous). This extra point is added just for the height-based fields like pressure and geometric height. So we have the following as an example:

air_pressure_at_interafce – on the interface (n+1 points)
air_pressure – cell centered (n points)
air_pressure_including_point_above_model_top – cell centered with an additional point above the model (n+1 points)

Since JEDI is adopting the CCPP standard, we need some way to distinguish these fields. We are proposing to add the including_point_above_model_top suffix.

[climbfuji]

I think there is already a standard name rule or more, depending on the use case, for this. The simplest example is the suffix _plus_one. There are also other qualifiers that can be used to distinguish, for example _for_radiation (in case the vertical levels for radiation are more or less than for other fields) and the distinction between levels and interfaces (half levels, full levels). Do you any of this will work for you?

[ss421]

Thankyou for the suggestion, I did not spot the _plus one. I see that _plus_one is defined in StandardNamesRules and used in Metadata-standard-names for: number_of_tracers_plus_one.

At the moment, we use _levels to distinguish between the two grid staggers. For the extra level we use the suffix _minus_one rather than _plus_one. I recall _plus_one was ruled out in favor of _minus_one but I was not part of the discussion in that case.

In terms of the new name, we wanted something descriptive and so opted for _including_point_above_model_top. I think _plus_one is a little ambiguous but I can ask others who have more of an opinion on this matter than me to contribute. This was discussed in jcsda-interanl/vader#109 (apologies to those that do not have access).

For context, the names we currently use in JEDI vs CCPP conforming names that we plan to adopt:

current JEDI name (non-CCPP conforming) => will become the following CCPP conforming name
air_pressure => air_pressure_at_interface
air_pressure_levels => air_pressure_including_point_above_model_top
air_pressure_levels_minus_one => air_pressure

where _including_point_above_model_top is the focus of the current PR.

[climbfuji]

Ok, thanks. Let's see what the other CCPP std name folks have to say.

[gold2718]

While I appreciate suffix rules, I think clarity is more important.
In particular, this "new" standard name will be defined on a different vertical dimension.
I would like both the name of the vertical dimension and the matching standard_name(s) to be clear as to purpose.
Is the only application a single point above the model top? How about something explanatory but a bit more general such as:
air_pressure_extended_upwards
vertical_layer_dimension_extended_upwards
??

[gold2718]

current => will become
air_pressure => air_pressure_at_interface
air_pressure_levels => air_pressure_including_point_above_model_top
air_pressure_levels_minus_one => air_pressure

Is this intended to be a suggestion for changing CCPP names? If no, I'm not sure how I am supposed to use this information.
These names were adopted years ago after lengthy discussion, I don't see any reason to change them.

[ss421]

current => will become
air_pressure => air_pressure_at_interface
air_pressure_levels => air_pressure_including_point_above_model_top
air_pressure_levels_minus_one => air_pressure

Is this intended to be a suggestion for changing CCPP names? If no, I'm not sure how I am supposed to use this information. These names were adopted years ago after lengthy discussion, I don't see any reason to change them.

Sorry, that comment is just for context, in particular related to the fact that we temporarily (as I understand it) adopted the _minus_one convention as described by the mapping. The _minus_one no longer makes sense when considering the CCPP standard. We plan to adopt the existing names: air_pressure_at_interface and air_pressure but we require a third air_pressure_including_point_above_model_top for fields that have the extra point.

I went back and edited the comment to hopefully clarify.

[ss421]

While I appreciate suffix rules, I think clarity is more important. In particular, this "new" standard name will be defined on a different vertical dimension. I would like both the name of the vertical dimension and the matching standard_name(s) to be clear as to purpose. Is the only application a single point above the model top? How about something explanatory but a bit more general such as: air_pressure_extended_upwards vertical_layer_dimension_extended_upwards ??

In our use cases, I believe we will only ever require the extra point but I take your point that a more general suffix may be useful. That said, I would prefer something that indicates there is only one point. May I clarify your suggestions:

1. Are there two suggested suffix here?:

air_pressure_extended_upwards
or
air_pressure_vertical_layer_dimension_extended_upwards

2. Do the two suggested suffix intend to convey that there could be any number of points above the top of the model?

[gold2718]

In our use cases, I believe we will only ever require the extra point but I take your point that a more general suffix may be useful. That said, I would prefer something that indicates there is only one point. May I clarify your suggestions:

1. Are there two suggested suffix here?:

air_pressure_extended_upwards or air_pressure_vertical_layer_dimension_extended_upwards

2. Do the two suggested suffix intend to convey that there could be any number of points above the top of the model?

Now it is my turn to try to clarify a badly worded suggestion.

My point is that if you ever define a variable such as air_pressure_extended_upwards or air_pressure_including_point_above_model_top, you will need standard names for its dimensions. One is likely horizontal_dimension but there is no appropriate standard name for the vertical dimension. I think that whatever the decision is on the new air pressure suffix, a new vertical dimension should also be defined that goes with it. At least in CCPP land, this might end up looking like:

air_pressure_extended_upwards(horizontal_dimension, vertical_dimension_extended_upwards)

or

air_pressure_including_point_above_model_top(horizontal_dimension, vertical_dimension_including_point_above_model_top)

or

air_pressure_extended_up_by_1(horizontal_dimension, vertical_dimension_extended_up_by_1)

Do you not need dimension names?

[ss421]

I see what you mean. I have focused purely on the vertical nature of the grids. Although most models have the staggering in both vertical and horizontal, all of the variables we are using in JEDI are centered horizontally but possibly staggered vertically. In reality, the wind field is staggered horizontally in the model but the wind field that is presented to JEDI is on cell centers – we perform the interpolation externally. The horizontal grid staggering is difficult to handle in generic DA software but there is real benefit from not interpolating so I would not rule it out entirely. However, it may never happen and from what I understand believe it is very unlikely to be included. There are of course more than JEDI in this discussion and of course other models may wish to include this information.

Looking to rule 4 in StandardNamesRules.rst: the suggestion is that the suffix at_interface relates to the vertical staggering. Since the at_interafce nomenclature is well defined, I wonder if the same logic could be applied – i.e.: adopt at_interface for vertical stager and at_horizontal_interface for points that are staggered in the horizontal dimension?

In terms of adding additional points in the vertical and horizontal direction. From Met Office model point of view, we will only extended by one point vertically. I like your suggestion:

air_pressure_extended_up_by_1

because it allows for the direction to be specified by the “up” in this case. Equally you could in principal extend “down” and “horizontal”. I think horizontal is best because any other descriptor is becoming specific about the grid used. You could say the same about the vertical but in the case of geophysical models we are safe here I believe.

Having said all of that, I don’t see that we the Met Office would need to include an additional point horizontally, below or more than 1 point.

[gold2718]

When it comes to horizontal dimension, we have not needed any staggering until now because the CCPP was designed for column-based physics which is almost always cell-centered grid average values. I think the main horizontal feature I see being needed is a way to incorporate 3-D calculations on the physics state. This is complicated by the various algorithms needed to perform such calculations on the wide variety of modern meshes in use so I see the need to add some sort of connectivity information as a highter priority at the moment.

[ss421]

Yes the horizontal aspect is more difficult to define and for the moment we (the Met Office and I believe JEDI) do not need a definition for it as all variables in JEDI are stored at the cell center (to my knowledge).

In terms of the vertical, we do have the requirement to add a way to denote the extra point and have the following options:

including_point_above_model_top - original suggestion
extended_up_by_1 - @gold2718 suggestion

I like the new suggestion and would be happy with either.

[climbfuji]

@gold2718 @ss421 What's the status of this discussion? Are we ok to proceed with extended_up_by_1 for the coordinate variable and the dimension, or are we looking for something else?

[gold2718]

@gold2718 @ss421 What's the status of this discussion? Are we ok to proceed with extended_up_by_1 for the coordinate variable and the dimension, or are we looking for something else?

By "coordinate variable"*, do you mean the physical quantity such as air pressure? If so, I'm fine with this. It would be great to hear from others (e.g., @grantfirl, @cacraigucar, @nusbaume looking at recent contributors).

• I think of the term "coordinate variable" as defined in the CF Conventions (cf, https://cfconventions.org/Data/cf-conventions/cf-conventions-1.10/cf-conventions.html#terminology).

[nusbaume]

I think I am personally fine with the following proposed solution (assuming I understood the discussion above correctly):

air_pressure_extended_up_by_1(horizontal_dimension, vertical_dimension_extended_up_by_1)

[ss421]

I'm happy with the suffix extended_up_by_1 and can open a PR if that is appropriate? @gold2718 @nusbaume @climbfuji

In terms of the dimension specifiers, where would they be included? I see there is:

horizontal_dimension: Size horizontal dimension
integer: units = count
vertical_layer_dimension: number of vertical layers
integer: units = count
vertical_interface_dimension: number of vertical interfaces
integer: units = count

in https://github.com/ss421/CCPPStandardNames/blob/main/Metadata-standard-names.md#dimensions.

so perhaps add the following:

vertical_layer_extended_up_by_1_dimension: number of vertical layers
integer: units = count

[mkavulich]

@ss421 That sounds like a good way to go forward, with the full name:

vertical_layer_extended_up_by_1_dimension: number of vertical layers extended up by 1 dimension
integer: units = count

[mkavulich]

@ss421 just pinging to make sure you saw my last comment. Did you intend to create a new PR, or will you update #51 with the recommended change?

[ss421]

Thanks @mkavulich. I planned to apply the update to a PR but have not yet gotten around to it. I will be able to do it within the next week though. What would you recommend - a new PR or update #51?

[climbfuji]

Thanks @mkavulich. I planned to apply the update to a PR but have not yet gotten around to it. I will be able to do it within the next week though. What would you recommend - a new PR or update #51?

[not speaking for Mike but] I think if you can simply update the existing PR #51 it's less work and we have to full conversation in there? Thanks for your efforts!

[ss421]

Thanks, I've updated the PR as discussed above. @mkavulich, Instead of:

vertical_layer_extended_up_by_1_dimension: number of vertical layers extended up by 1 dimension
integer: units = count

I opted for:

vertical_layer_dimension_extended_up_by_1: number of vertical layers extended up by 1
integer: units = count

as I feel vertical_layer_dimension_extended_up_by_1 is clearer. Also, I did not add dimension to description (long name) to be consistent with the other entries. Happy to change it further.

[mkavulich]

Resolved by #51. Looks like this wasn't automatically closed with #51 for some reason; closing manually.