Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsideration of Add four wind CF variables #73? #77

Open
MarekWlasak opened this issue Oct 9, 2024 · 10 comments
Open

Reconsideration of Add four wind CF variables #73? #77

MarekWlasak opened this issue Oct 9, 2024 · 10 comments

Comments

@MarekWlasak
Copy link

MarekWlasak commented Oct 9, 2024

In #73 we came up with 4 new wind CF variable names: (I approved this before the final choice for the names was chosen!)

I apologize to all concerned who have been implementing the new variables and the work they have done. (In particular @svahl991 @shlyaeva @ncrossette)

The new variables are:

  • atmosphere_horizontal_streamfunction: Scalar function describing the stream lines of the wind
  • atmosphere_horizontal_velocity_potential: Scalar potential of the wind
  • atmosphere_upward_absolute_vorticity: The kth component of the curl of the vector wind field. The curl itself is assuming wind is a 3D object.
  • divergence_of_wind: The (horizontal) divergence of the 2-D vector wind field

I have a few concerns above these names:

  1. These variables go together ... and yet some have a atmosphere tag and others dont. So there is no consistency in the naming
  2. The "atmosphere_" tag is not really correct (in the sense that you can have horizontal_streamfunction in the ocean or on a regional domain. You could run the code associated with this on an oceanic aquaplanet.)
  3. divergence_of_the_wind (although consistent with the CF understanding that a wind is by definition 2D) is misleading to most model developers who consider the wind as a 3D vector. This becomes problematic in high resolution modelling especially around mountains. It is only a matter of time where someone will naively misuse this name and consider it to mean the 3D divergence. This is why adding "horizontal_" in front would greatly reduce the risk of misuse of the variable.
  4. We need a name of the 3D divergence even if we don't use it at present. Maybe the presence of this variable will help divergence_of_wind not to be misused.

Suggestions

atmosphere_horizontal_streamfunction -> horizontal_streamfunction
atmosphere_horizontal_velocity_potential -> horizontal_velocity_potential
atmosphere_upward_absolute_vorticity -> upward_absolute_vorticity We need to update the description to include The kth component of the curl of the vector wind field.
divergence_of_wind (keep as is)
divergence_of_wind_and_upward_air_velocity (add this to help clarity - 3D divergence!)

@ncrossette
Copy link

ncrossette commented Oct 9, 2024

I agree there is an unsatisfying inconsistency here, particularly for the divergence of wind. If it were up to me, I would prefer to rename this to atmosphere_horizontal_divergence to be consistent with the previous three variables (and to be a little more explicit that it is the 2D divergence). Since, in principle (but not yet in the CCPP), there are equivalent quantities in the ocean for streamfunction and velocity_potential we should keep the atmosphere prefix.

@ncrossette
Copy link

For a shorter name, maybe we could use air instead of atmosphere? So:

divergence_of_wind -> air_horizontal_divergence
atmosphere_horizontal_streamfunction -> air_horizontal_streamfunction
atmosphere_horizontal_velocity_potential -> air_horizontal_velocity_potential
atmosphere_upward_absolute_vorticity -> air_upward_absolute_vorticity

  • We need to update the description to include The kth component of the curl of the vector wind field.

@MarekWlasak
Copy link
Author

@ncrossette - I do like the names that you propose.

@climbfuji
Copy link
Collaborator

Is air the right term here? Does CF say anything about that / prefer air or atmosphere or do we have precedence for either of the two (or both ...) in our dictionary. I see a two-fold use of air in our dictionary, one sounds like referring to the properties of the medium itself (air_temperature, air_pressure, air_potential_temperature) and then one referring to a quantity IN that medium volume_extinction_in_air_due_to_aerosol_particles. For atmosphere, it seems to be either the latter or something related to atmosphere_model. I think using air makes sense. But I would like to hear from the other reviewers and long-term std name maintainers, please.

@MarekWlasak
Copy link
Author

@climbfuji - I think air is fine

@dustinswales
Copy link
Collaborator

dustinswales commented Oct 16, 2024

Atmosphere is a special phrase to be used instead of the local (grid-point) in medium component for large scale (not by grid-point) fields. (e.g. diagnostics that are in_atmosphere since they are averaged over the whole domain (or in_basin, etc...).)
Also, in this context, atmosphere (or better yet air) is the medium, so it should be a suffix, not a prefix.

Following the rules is confusing for a couple reasons.

  1. In the section on generic names, the horizontal prefix in two of the names (horizontal_streamfunction and horizontal_velocity_potential) makes these not terribly generic, complicating the extensions being proposed. Maybe it would be more clear if these base generic names were simply streamfunction and velocity_potential? and...
  2. Extend the component prefixes in the rules to include horizontal (and vertical) as acceptable prefixes. Hierarchically, I think this makes sense since component could be total = horizontal (zonal + meridional) + vertical.
  3. Building on the previous point, Convergent, Divergent and Rotational could be additional components, at least in the context of fluid flow.
  4. Convergence and Divergence should be there own generic names, alongside Streamfunction and velocity_potential.

Following the rules for constructing names:
[component] standard_name [at level] [in medium] [due_to process] [assuming condition]

The names would be:
horizontal_divergence_in_air
horizontal_streamfunction_in_air
horizontal_velocity_potential_in_air
upward_absolute_vorticity_in_air

@ncrossette
Copy link

What is the guideline for putting the medium as a suffix vs prefix, like it's done with these variables?:

air_pressure_at_top_of_atmosphere_model
air_pressure_at_sea_level
air_pressure_at_surface
surface_pressure_of_dry_air
air_temperature
air_temperature_on_previous_timestep

@climbfuji
Copy link
Collaborator

@dustinswales
Copy link
Collaborator

What is the guideline for putting the medium as a suffix vs prefix, like it's done with these variables?:

air_pressure_at_top_of_atmosphere_model
air_pressure_at_sea_level
air_pressure_at_surface
surface_pressure_of_dry_air
air_temperature
air_temperature_on_previous_timestep

Fair point.
I think we've always tried to stick with the CF conventions as much as possible, but with all the variants on the base/generic names that we need makes this darn near impossible going forward. I don't have a solution, nor can I make such a decision.

@svahl991
Copy link
Collaborator

What is the guideline for putting the medium as a suffix vs prefix, like it's done with these variables?:

air_pressure_at_surface
surface_pressure_of_dry_air

At least regarding the suffix/prefix situation regarding surface: the rule has been changed for this to now always be a suffix, not a prefix, in #72. However, not all surface names have been updated so that they match the new rule. I hope this happens soon, because we recently added many new names to JEDI with the _at_surface suffix, in anticipation of these names getting changed in the CCPP standard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests