Add new standard names from NCAR idealized physics schemes#56
Add new standard names from NCAR idealized physics schemes#56nusbaume merged 5 commits intoESCOMP:mainfrom
Conversation
… physics schemes.
nusbaume
requested review from
cacraigucar,
climbfuji,
grantfirl and
mkavulich
nusbaume
added
the
needs discussion
| <standard_name name="vertically_integrated_total_water_of_current_state"> | ||
| <type kind="kind_phys" units="kg m-2">real</type> | ||
| </standard_name> | ||
| <standard_name name="heating_rate" |
There was a problem hiding this comment.
This variable name feels very vague, could it be made more specific?
If the standard name needs to be kept at is, it definitely needs a more specific long_name entry at the very least.
There was a problem hiding this comment.
Mathematically this quantity is equal to d/dt(Cp*T), where Cp is the specific heat of (dry) air at constant pressure, and T is the Air Temperature. After discussing with the scientists an alternative name (which is longer, but more specific), could be:
tendency_of_dry_air_enthalpy_at_constant_pressure
Would that work for you? Alternatively I could also do :
tendency_of_composition_dependent_specific_heat_of_dry_air_at_constant_pressure_times_air_temperature
Let me know if you have a preference (or if you think one of these should be in the long_name instead). Also pinging @PeterHjortLauritzen to make sure I have this correct.
There was a problem hiding this comment.
I think tendency_of_dry_air_enthalpy_at_constant_pressure is much better, despite how much the term "enthalpy" gives me undergrad thermodynamics flashbacks. We could also keep the standard name as "heating_rate_of_dry_air" and include the enthalpy descriptor as the long name.
It occurs to me that there is really no guidance at all for "long names" in the standards. Maybe a discussion topic for a future meeting?
There was a problem hiding this comment.
Yes, @nusbaume, the new standard name is much clearer. Thanks. @mkavulich Long names have always just functioned as documentation basically. The framework ignores them. They can be context-dependent, i.e. have differences between metadata files, if it makes sense to do so.
There was a problem hiding this comment.
@mkavulich @grantfirl The standard name has now been changed. Thanks!
| long_name="CCPP physics scheme name"> | ||
| <type kind="len=64" units="none">character</type> | ||
| </standard_name> | ||
| <standard_name name="ccpp_constituent_properties" |
There was a problem hiding this comment.
Out of curiosity, can you point me to how these constituent variables are being used in SIMA? I'm curious about the specifics of the use case (for example, why there are minimum but not maximum values).
There was a problem hiding this comment.
Sure! You can find an example of us using it to calculate geopotential here: https://github.com/ESCOMP/atmospheric_physics/blob/main/utilities/geopotential_temp.F90
with the associated metadata file here: https://github.com/ESCOMP/atmospheric_physics/blob/main/utilities/geopotential_temp.meta).
We also use them for our negative constituent adjuster here: https://github.com/ESCOMP/atmospheric_physics/blob/main/utilities/qneg.F90
with the associated metadata file here: https://github.com/ESCOMP/atmospheric_physics/blob/main/utilities/qneg.meta)
If you have any questions or concerns about these routines or the general use of these data structures just let me know!
| Optional CCPP variables | ||
| * `scheme_name`: CCPP physics scheme name | ||
| * `character(kind=len=64)`: units = none | ||
| * `ccpp_constituent_properties`: CCPP Constituent Properties |
There was a problem hiding this comment.
Do we need to have "CCPP" in the standard names added here? Aren't all standard names "CCPP" standard names in this context?
There was a problem hiding this comment.
I think at least this particular name should have ccpp in its name, as it will be the CCPP derived data type. I don't have a strong feeling for the other variables listed below this one.
There was a problem hiding this comment.
Maybe it's OK to keep ccpp in the standard name and maybe add a rule that all variables that start with ccpp_X are provided by the framework.
There was a problem hiding this comment.
I have updated the rules to make it clear that any standard name that starts with ccpp_ should be a framework-provided variable.
|
@mkavulich @grantfirl @cacraigucar I forgot to mention that I also added some changes to |
|
@nusbaume I'll approve once you commit those couple of changes that we discussed. Please tag me with @ when you're done so that I get an email (that I hopefully see!). |
mkavulich
left a comment
mkavulich
left a comment
There was a problem hiding this comment.
Sorry it took so long to get back to this, thanks for making those changes and linking that info 👍
mkavulich
removed
the
needs discussion
4 participants
This PR adds some new CCPP standard names that are currently being used within SIMA for NCAR idealized physics schemes.
Along with the standard names themselves, I also added a couple extra sections for some variables that I thought wouldn't fit very nicely elsewhere. At some point I think it would be worth discussing the organization of the standard names a little more, as there are some standard names that are listed under specific GFS DDTs but which are probably more universal than that (e.g.
mpi_rank). However, I don't believe this potential organizational concern needs to be resolved for this particular PR.Finally, please note that some of the links to the new sections in the generated markdown file will be broken until PR #55 has been merged. Thanks!