Update wind derivative/integral names

[ncrossette]

Following up on the discussion in #77, this updates the streamfunction, velocity_potential, vorticity, and divergence names to:

air_horizontal_streamfunction
air_horizontal_velocity_potential
air_upward_absolute_vorticity
air_horizontal_divergence

Also, the description of air_upward_absolute_vorticity is updated to indicate that it is the kth/upward component of the curl.

[climbfuji]

As per discussion in #77, I agree with these names

[nusbaume]

Looks good to me!

[ss421]

Thankyou. The update is consistent with the agreed names in #77.

[dustinswales]

I have several problems with these names that I mentioned in #77, but most importantly they don't follow our own rules.
If we are going to move the medium descriptor from suffix to prefix, the rules need to be updated. Also, what are the implications on current variable names? (Are there variables out there that follow the previous convention of using medium as a suffix that need to be changed?)

[climbfuji]

I have several problems with these names that I mentioned in #77, but most importantly they don't follow our own rules. If we are going to move the medium descriptor from suffix to prefix, the rules need to be updated. Also, what are the implications on current variable names? (Are there variables out there that follow the previous convention of using medium as a suffix that need to be changed?)

@dustinswales I am not following, sorry. You are right that a property IN a medium uses the suffix in_medium. But as @ncrossette explained in #77 (comment), these standard names are describing the property OF the medium (air), not the property of something IN that medium. I think this is an important distinction.

Sorry of this doesn't make sense, I am slowly but certainly getting confused myself.

[ncrossette]

I have several problems with these names that I mentioned in #77, but most importantly they don't follow our own rules. If we are going to move the medium descriptor from suffix to prefix, the rules need to be updated. Also, what are the implications on current variable names? (Are there variables out there that follow the previous convention of using medium as a suffix that need to be changed?)

@dustinswales Maybe the rules need to be updated, but I think there is a subtle but important distinction that needs to be made regarding the medium. It seems like the current rule for the medium suffix is intended for chemical or physical quantities that exist WITHIN a particular medium (but are unrelated to the medium) like:

surface_upward_heat_flux_in_air
mass_content_of_cloud_ice_in_atmosphere_layer
mass_content_of_water_in_top_soil_layer
free_convection_layer_thickness_in_sea_water
mole_fraction_of_ozone_in_air

In the first example above, the air itself is not 'flux-ing' upward, energy is traveling upwards IN the air. For variables like this, the _in_MEDIUM suffix makes sense and seems appropriate.

But, there are also physical quantities that are OF the medium itself, like:

air_temperature
air_pressure
soil_temperature

For these variables it is more vague and less accurate to say temperature_in_air.

The variables that are the subject of this PR fall into this second category.

[climbfuji]

I have several problems with these names that I mentioned in #77, but most importantly they don't follow our own rules. If we are going to move the medium descriptor from suffix to prefix, the rules need to be updated. Also, what are the implications on current variable names? (Are there variables out there that follow the previous convention of using medium as a suffix that need to be changed?)

@dustinswales Maybe the rules need to be updated, but I think there is a subtle but important distinction that needs to be made regarding the medium. It seems like the current rule for the medium suffix is intended for chemical or physical quantities that exist WITHIN a particular medium (but are unrelated to the medium) like:

surface_upward_heat_flux_in_air
mass_content_of_cloud_ice_in_atmosphere_layer
mass_content_of_water_in_top_soil_layer
free_convection_layer_thickness_in_sea_water
mole_fraction_of_ozone_in_air

In the first example above, the air itself is not 'flux-ing' upward, energy is traveling upwards IN the air. For variables like this, the _in_MEDIUM suffix makes sense and seems appropriate.

But, there are also physical quantities that are OF the medium itself, like:

air_temperature
air_pressure
soil_temperature

For these variables it is more vague and less accurate to say temperature_in_air.

The variables that are the subject of this PR fall into this second category.

I agree with your assessment (#78 (comment))

[dustinswales]

If there is a new convention to be followed, the rules need to be updated, and changes should propagate. That's my only point.

From
[component] standard_name [at level] [in medium] [due_to process] [assuming condition]
to
[medium A] [component] standard_name [at level] [in medium B] [due_to process] [assuming condition]
Ex: air_temperature_in_cloud
^Not sure it mediumA or component should be first here?

Another point, why do we have the component, horizontal, built into the base name definitions of streamfunction and convergence. This is confusing, since these quantities could have a vertical component

[climbfuji]

Regarding horizontal: I think #77 and this PR are about the horizontal wind fields (except the upward vorticity), therefore horizontal is correct.

[climbfuji]

@ncrossette I am very sorry for this but we have to hold off for a tiny little longer on merging this PR. We discussed for almost an hour whether air in these names should be a prefix or a suffix _of_air.

At least, we've agreed that the distinction of the property that we want to describe (air) in this case is something different than the medium something we wanto to describe resides in (e.g. _in_cloud).

Basically, the question is whether describing the temperature of air in cloud should be

air_temperature_in_cloud

or

temperature_of_air_in_cloud

If you browse through the existing standard names, you can find plenty of examples for either of these, but notably we often find air_ as a prefix, but other objects as suffix, for example cumulative_boundary_flux_of_total_energy.

Most of us would agree that air_temperature sounds is more commonly used than temperature_of_air in the numerical world - but not necessarily in spoken language.

Conversely, total_energy_cumulative_boundary_flux sounds weird/wrong.

I wanted to get your thoughts and that of the other reviewers. Basically, we have three options here:

1. Only allow objects that are being described by a variable as prefix (air_temperature, total_energy_cumulative_boundary_flux).
2. Only allow objects that are being described by a variable as suffx (temperature_of_air, cumulative_boundary_flux_of_total_energy).
3. Allow both with the requirement that people (and the CCPP framework) treat them as interchangeable. That requires some CCPP framework engineering so that it can match those names with each other.

Since we want to move forward with this PR, but also avoid JEDI having to change their names again, it would be good if we could decide on this important question rather quickly. wonder if a PR review/discussion the right place for this.

The CCPP framework devs are going to meet for a dedicated std names discussion next Thursday Nov 1 at 9.30 am MT. I think it would make sense for interested JCSDA/UKMO people to attend this meeting. I know that there is a 9-10am JEDI general meeting, but maybe you can sneak out 30 minutes earlier?

[ncrossette]

@climbfuji Is that going to be Thurs. Oct 31st?

[dudhia]

I prefer [medium] [variable] [location] as a rule [variable] may include qualifiers such as upward for fluxes.

…

On Thu, Oct 24, 2024 at 10:44 AM Dom Heinzeller ***@***.***> wrote: ***@***.**** requested changes on this pull request. @ncrossette <https://github.com/ncrossette> I am very sorry for this but we have to hold off for a tiny little longer on merging this PR. We discussed for almost an hour whether air in these names should be a prefix or a suffix _of_air. At least, we've agreed that the distinction of the property that we want to describe (air) in this case is something different than the medium something we wanto to describe resides in (e.g. _in_cloud). Basically, the question is whether describing the temperature of air in cloud should be air_temperature_in_cloud or temperature_of_air_in_cloud If you browse through the existing standard names, you can find plenty of examples for either of these, but notably we often find air_ as a prefix, but other objects as suffix, for example cumulative_boundary_flux_of_total_energy. Most of us would agree that air_temperature sounds is more commonly used than temperature_of_air in the numerical world - but not necessarily in spoken language. Conversely, total_energy_cumulative_boundary_flux sounds weird/wrong. I wanted to get your thoughts and that of the other reviewers. Basically, we have three options here: 1. Only allow objects that are being described by a variable as prefix (air_temperature, total_energy_cumulative_boundary_flux). 2. Only allow objects that are being described by a variable as suffx ( temperature_of_air, cumulative_boundary_flux_of_total_energy). 3. Allow both with the requirement that people (and the CCPP framework) treat them as interchangeable. That requires some CCPP framework engineering so that it can match those names with each other. Since we want to move forward with this PR, but also avoid JEDI having to change their names again, it would be good if we could decide on this important question rather quickly. wonder if a PR review/discussion the right place for this. The CCPP framework devs are going to meet for a dedicated std names discussion next Thursday Nov 1 at 9.30 am MT. I think it would make sense for interested JCSDA/UKMO people to attend this meeting. I know that there is a 9-10am JEDI general meeting, but maybe you can sneak out 30 minutes earlier? — Reply to this email directly, view it on GitHub <#78 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77CVPTSBKEO6OZLUU7LZ5EPWLAVCNFSM6AAAAABQKZMM6WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGOJTGIZDGOBSGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ncrossette]

Is the meeting still happening tomorrow?

To me, air_temperature_in_cloud is much preferable over temperature_of_air_in_cloud. I am very against using an _of_ preposition in variable names unless absolutely necessary, but that is just my personal opinion and I am unfamiliar with the rules and philosophy behind the CCPP conventions.

Also, I don't see the (need for a) conflict between having both cumulative_boundary_flux_of_total_energy and air_temperature as standard names. 'Flux' and 'temperature' are ontologically different quantities, temperature is a state quantity, and flux is not. Trying to create one strictly rigid standard to rule them all seems to me like a recipe for trouble; coming up with good names is more of an art than a science.

I don't feel like these thoughts are particularly helpful to this conversation, and there is another unfortunate logistical hurdle on our end for these variable names... We have all the pull requests ready to merge that will change names to the set (as they are now) in this PR. If these names change, all the PRs (from JCSDA, NOAA, and UKMO) will also have to change (a second time).

@ncrossette I am very sorry for this but we have to hold off for a tiny little longer on merging this PR. We discussed for almost an hour whether air in these names should be a prefix or a suffix _of_air.

At least, we've agreed that the distinction of the property that we want to describe (air) in this case is something different than the medium something we wanto to describe resides in (e.g. _in_cloud).

Basically, the question is whether describing the temperature of air in cloud should be

air_temperature_in_cloud

or

temperature_of_air_in_cloud

If you browse through the existing standard names, you can find plenty of examples for either of these, but notably we often find air_ as a prefix, but other objects as suffix, for example cumulative_boundary_flux_of_total_energy.

Most of us would agree that air_temperature sounds is more commonly used than temperature_of_air in the numerical world - but not necessarily in spoken language.

Conversely, total_energy_cumulative_boundary_flux sounds weird/wrong.

I wanted to get your thoughts and that of the other reviewers. Basically, we have three options here:

1. Only allow objects that are being described by a variable as prefix (air_temperature, total_energy_cumulative_boundary_flux).
2. Only allow objects that are being described by a variable as suffx (temperature_of_air, cumulative_boundary_flux_of_total_energy).
3. Allow both with the requirement that people (and the CCPP framework) treat them as interchangeable. That requires some CCPP framework engineering so that it can match those names with each other.

Since we want to move forward with this PR, but also avoid JEDI having to change their names again, it would be good if we could decide on this important question rather quickly. wonder if a PR review/discussion the right place for this.

The CCPP framework devs are going to meet for a dedicated std names discussion next Thursday Nov 1 at 9.30 am MT. I think it would make sense for interested JCSDA/UKMO people to attend this meeting. I know that there is a 9-10am JEDI general meeting, but maybe you can sneak out 30 minutes earlier?

[gold2718]

I do not have an opinion on these changes.

[mkavulich]

@ncrossette Yes, we will be discussing this PR tomorrow at 9:30am mountain time. I have sent you an invite to this meeting in case you would like to attend.

[climbfuji]

Let's merge this as is to allow JCSDA to move forward. After this has been merged, we'll check with JCSDA if anything else needs to go in urgently before we tag the standard names dictionary as is as version 0.1 so that folks have something to refer to.

I will note that we will be working on an overhaul of the rules and the list of known standard names in the future, but that's going to take a bit of time.

[svahl991]

@climbfuji , Regarding the tagging of the dictionary: it doesn't appear that all the names in the dictionary have been updated to match the surface rule change introduced in #72. When JCSDA did our naming code sprint a few weeks ago, we assumed that this would be happening quickly, and so put in surface names that matched the new rule, not the names currently in the dictionary. So it would be helpful for us if those changes could go in before tagging, if the purpose of the tag is to match what JCSDA is using.

[climbfuji]

@climbfuji , Regarding the tagging of the dictionary: it doesn't appear that all the names in the dictionary have been updated to match the surface rule change introduced in #72. When JCSDA did our naming code sprint a few weeks ago, we assumed that this would be happening quickly, and so put in surface names that matched the new rule, not the names currently in the dictionary. So it would be helpful for us if those changes could go in before tagging, if the purpose of the tag is to match what JCSDA is using.

Agreed. The problem will be to find someone who has the time to do that.

[mkavulich]

@svahl991 I think there are going to be a ton of inconsistencies to be found in the existing standard names, breaking both new rules and old. We will hold off on making the tag for now, please keep us posted if you're able to provide the remaining updates based on the latest JCSDA work.