Update StandardNamesRules.rst: changesurface prefix to _at_surface suffix

[climbfuji]

This PR changes the rules (and the rules only) to make surface a suffix (at_surface) rather than a prefix. This proposed change was discussed in last week's CCPP framework meeting and is a departure from the CF conventions, which use surface_ as a prefix. The motivation for this change is to maintain consistency with all other level qualifiers that are used as _at_level qualifier (i.e. as suffix).

[gold2718]

I am okay with surface_ prefixes (described below) but will go along with the majority (or a stronger argument).

[gold2718]

Personally, I am okay with the surface_ variables that define quantities at the surface. This is partially because that is the way CF defines variables (which allows us to follow rule 1 more closely) and partially because in an atmosphere model, surface variables are usually derived from other model variables.

[svahl991]

I tend to agree with @gold2718 , and would go a bit further to say I'd prefer to keep the surface_* prefix. I understand that this means the surface layer remains named differently than the other specific layers, and that's not ideal. But I also don't think it's ideal, and is potentially confusing, to create a new inconsistency with CF given rule number 1 of the naming convention. Making a change would also mean that a bunch of variable names in models that people have accepted for years (because they are CF) would need to change in order to stay compliant with CCPP naming.

I don't think either way is perfect, and my opinion is that the current imperfection seems livable, and possibly better than the alternative.

[climbfuji]

Can the other reviewers from the CCPP framework meeting last week please state what their preferences are? I don't have a strong opinion myself, the reason for creating the draft PR was the discussion that happened last week in the framework meeting.

[cacraigucar]

I personally prefer consistency within the CCPP names when the CF conventions are inconsistent.

The CF conventions for the most part have surface as a prefix (though they do have the single variable predominant_precipitaton_type_at_surface which breaks that convention).

Looking for other "level" indicators, sea_level, cloud_top and top_of all are suffixes and use the qualifier at_ before all of them.

My preference is to have at_<level> be the standard whether it is surface, sea_level or something else. When the CF names are viewed in this way, I believe that at_<level> is used most frequently.

All of this said, I am a software engineer and not a scientist. If the science community has the surface_ prefix firmly entrenched, I defer to that.

After the decision is made on whether surface is a prefix or a suffix, then the CCPP dictionary entries needs to be modified so that they are consistent (there are examples of both) and the StandardNamesRules rule#2 needs to be modified from allowing both:

Current rule#2: [surface] [component] standard_name [at surface] [in medium] [due_to process] [assuming condition]

[climbfuji]

I personally prefer consistency within the CCPP names when the CF conventions are inconsistent.

The CF conventions for the most part have surface as a prefix (though they do have the single variable predominant_precipitaton_type_at_surface which breaks that convention).

Looking for other "level" indicators, sea_level, cloud_top and top_of all are suffixes and use the qualifier at_ before all of them.

My preference is to have at_<level> be the standard whether it is surface, sea_level or something else. When the CF names are viewed in this way, I believe that at_<level> is used most frequently.

All of this said, I am a software engineer and not a scientist. If the science community has the surface_ prefix firmly entrenched, I defer to that.

After the decision is made on whether surface is a prefix or a suffix, then the CCPP dictionary entries needs to be modified so that they are consistent (there are examples of both) and the StandardNamesRules rule#2 needs to be modified from allowing both:

Current rule#2: [surface] [component] standard_name [at surface] [in medium] [due_to process] [assuming condition]

I have to admit that @cacraigucar is making a good point here and that I now tend to agree with the idea of making at_surface a suffix.

[grantfirl]

Even though, in my experience, land surface and physics folks tend to use the prefix surface* in spoken (English) language for things like latent heat flux (which is probably why the CF folks accept both surface as a prefix and suffix), I also agree that being consistent across all standard names for using the suffix form is cleaner programatically. It is also more common among non-English languages to have adjectives following the noun. See https://wals.info/feature/87A#2/18.0/152.9.

[mkavulich]

These are my thoughts, but in my opinion they represent the consensus of our discussion at today's CCPP framework meeting.

The number one mission of the standard names is to maintain a set of unique variable names so that physical quantities can be unambiguously mapped to each other across applications. In order to be able to maintain a sufficiently detailed, yet unambiguous naming convention that is easily extensible to arbitrary physical quantities as needed, consistency is important. As others have mentioned above, we have inherited an inconsistent set of names from the CF conventions, and so in order to achieve consistency, we will have to break with those inherited conventions.

Furthermore, having consistent rules will keep arguments over the best name for a particular physical quantity to a minimum going forward. Setting a very simple rule to cover a wide range of cases (all variables specific to a particular level must be disambiguated with a suffix _at_[level]) allows us to keep the rule set as minimal as possible.

[mkavulich]

Is there a difference between "toa" (defined as "top of atmosphere") and "top of atmosphere model"?

This may be worthy of a separate discussion, if so I won't hold up this PR but we can address it later.

[climbfuji]

If that question is directed to me than I don't have a definitive answer for you, sorry.

[climbfuji]

Thanks for your thoughtful comment @mkavulich - I'll leave it to you to decide whether you want to wait for more approvals/comments or merge it now.

[svahl991]

Given the decision that's apparently been arrived at, I believe Rule number 1, lines 24-27, should be removed or amended as part of this PR since it is no longer true as stated. I think it will be misleading to keep it as-is, especially since it sits at the top of the rule list.

[nusbaume]

Changing the surface descriptor to a suffix is fine with me. Thanks!

[climbfuji]

@mkavulich I think we are good to merge. After this PR, someone needs to change all existing standard names in this repo. And then we need to go and clean up the models.

[svahl991]

We are in the midst of our variable renaming code sprint in JEDI this week. We are wondering how a couple of the CCPP names will be changing as a result of this PR, so we can change to the name that will be the standard instead of what is current.

The names we're curious about are:

• surface_skin_temperature
• surface_skin_temperature_over_land

will these become

• skin_temperature_at_surface? Or just skin_temperature? (the former seems redundant)
• skin_temperature_over_land_at_surface?

Because we are "sprinting" this week, a rapid decision on this would be super helpful. We don't need a CCPP PR quickly, but just a handshake agreement on what the new name will be would be great.

Thanks!

[climbfuji]

If skin_temperature_at_surface seems redundant, then surface_skin_temperature should be redundant, too?

[svahl991]

If skin_temperature_at_surface seems redundant, then surface_skin_temperature should be redundant, too?

Yes, if you ask me surface_skin_temperature is also redundant. But I'm not a scientist so maybe I'm wrong. But if I'm right, the question is whether we remove the redundancy when we rename, or keep it.

[climbfuji]

Any meteorologists or related scientists out there? Two computational scientists with other backgrounds in science need help.

[dudhia]

While I agree that *at_surface is good for variables that might exist at other levels, I also see many standard names beginning with surface, especially fluxes, and it would be too much to enforce such a change to *at_surface. surface_skin_temperature has redundancy issues, but I would either leave it or shorten to skin_temperature.

[travissluka]

Any meteorologists or related scientists out there? Two computational scientists with other backgrounds in science need help.

If you want input from a third computational scientist and one who only really knows about the ocean:
skin is a qualifier for the type of surface. surface_temperature by itself is vague and indicates "somewhere near the surface but I dont' really know where". Adding _skin, _subskin, etc more precisely defines where in the surface region. So, yes, I agree that surface is redundant when skin is provided and so could be removed.

[dudhia]

It also surprised me that in CF, the word skin only applied to the sea surface, while I did not find a land skin temperature there.

[dustinswales]

Meteorologically, surface_skin_temperature is not the same as the skin_temperature. I believe these come from the remote sensing world.
For skin_temperature, skin refers to the temperature of a theoretical thin layer in the atmosphere that is approximately a graybody (e.g. tropopause)
For surface_skin_temperature, skin refers to the temperature of a thin layer in the atmosphere adjacent to the surface, at which is in thermal equilibrium with the underlying surface.
Surface_temperature, or temperature_at_surface, is exactly that.

[climbfuji]

While I agree that *at_surface is good for variables that might exist at other levels, I also see many standard names beginning with surface, especially fluxes, and it would be too much to enforce such a change to *at_surface. surface_skin_temperature has redundancy issues, but I would either leave it or shorten to skin_temperature.

@dudhia We've unfortunately/fortunately (?) moved past this discussion a couple of weeks ago when there was an overwhelming agreement to do away with the surface_ prefix and instead use an _at_surface suffix.

[svahl991]

Meteorologically, surface_skin_temperature is not the same as the skin_temperature. I believe these come from the remote sensing world.
For skin_temperature, skin refers to the temperature of a theoretical thin layer in the atmosphere that is approximately a graybody (e.g. tropopause)
For surface_skin_temperature, skin refers to the temperature of a thin layer in the atmosphere adjacent to the surface, at which is in thermal equilibrium with the underlying surface.
Surface_temperature, or temperature_at_surface, is exactly that.

Thank you @dustinswales ! This is great information. So do I understand you correctly that surface_skin_temperature is equivalent to temperature_at_surface? Is there a need for both names?

Assuming some version of the name surface_skin_temperature is still needed, and given the naming rule change in this PR, would it be appropriate to change surface_skin_temperature to skin_temperature_at_surface?

[dustinswales]

@ss421 surface_skin_temperature is not equivalent to the surface_temperature. I think there should be three distinct names: surface_skin_temperature (or skin_temperature_at_surface), skin_temperature (skin_temperature), surface_temperature (or temperature_at_surface)

[svahl991]

@dustinswales Thanks for clarifying. Sorry I misunderstood your initial comment.

Given this explanation, it seems to me that surface_skin_temperature should be changed to skin_temperature_at_surface in CCPP, otherwise the surface naming in CCPP would be pretty confusing. But I've been wrong before.

One more question while we're on the topic: what is surface_skin_temperature_over_land? Is this the same as surface_skin_temperature with a land mask applied?

[dudhia]

@climbfuji there are a lot of fluxes beginning with surface, surface_downwelling etc.. Is the plan to change all of those too?

[climbfuji]

@climbfuji there are a lot of fluxes beginning with surface, surface_downwelling etc.. Is the plan to change all of those too?

Yes, based on the lengthy discussion in #72 and in several meetings, it is.

[dudhia]

@climbfuji OK, not saying it's wrong, just a big change.

[climbfuji]

I know, that's why it was such a lengthy discussion. And that's why we asked for many approvals before merging it.

[dustinswales]

I created this figure real quick to help.

[climbfuji]

@dustinswales Thank you! I think figures like this would be very helpful if they were kept in the repository and referenced by the standard name rules / standard name dictionary. There is so much confusion about the terminology "levels", "layers", "interfaces", "surface", ...

[travissluka]

@climbfuji to make it even more confusing.... something to keep in mind, for the ocean (and presumably land, though I'm not a land person) you have the exact same variable names, but going in the opposite vertical direction. Therefore the air surface skin temperature and the ocean surface skin temperature are not the same things (the only variable that should be shared between the components, I think, is the surface temperature that happens at the interface)