[release/v1] Fifth major update in v1 branch: Better information on units, remove kind, clarify disallowed terms
#124
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… specific_humidity and amount
… rename dry_air_density --> density_of_dry_air, make "dry air" a base name rather than density of dry air
mkavulich
requested review from
MayeulDestouches,
cacraigucar,
climbfuji,
dustinswales,
gold2718,
grantfirl,
mattldawson,
mwaxmonsky,
nusbaume,
peverwhee,
ss421 and
svahl991
as code owners
nusbaume
approved these changes
Sep 6, 2025
Collaborator
nusbaume
left a comment
nusbaume
left a comment
There was a problem hiding this comment.
Thanks @mkavulich! I had a few questions, but nothing that should hold up this particular PR.
standard_names.xml
Outdated
| </standard_name> | ||
| <standard_name name="specific_heat_of_dry_air_at_constant_pressure"> | ||
| <type kind="kind_phys" units="J kg-1 K-1">real</type> | ||
| <standard_name name="fresh_liquid_water_density_at_0c" |
Collaborator
There was a problem hiding this comment.
Should this be density_of_fresh_liquid_water_at_0c in order to better follow standard name rules?
standard_names.xml
Outdated
| </standard_name> | ||
| <standard_name name="do_lagrangian_vertical_coordinate" | ||
| <standard_name name="flag_for_lagrangian_vertical_coordinate" |
Collaborator
There was a problem hiding this comment.
Was there a reason this change was made? I thought there was a general desire to try and avoid flag_for_X because it can be ambiguous as to what a "True" value actually means. However maybe I have been misunderstanding what the consensus is?
Jesse's suggestion Co-authored-by: Jesse Nusbaumer <nusbaume@ucar.edu>
mkavulich
added a commit
that referenced
this pull request
Dec 8, 2025
## Description This PR merges The `release/v1` branch into the `main` branch. The `release/v1` branch was split off from `main` about a year ago, with the intention to make major rules and name changes to improve the consistency and maintainability of both the rules and the names, without giving major inconveniences/disruption to those currently making use of the main branch. After a year of discussion and changes, it is time to bring these changes to their final resting place in the main branch. The major breaking and/or non-back-compatible changes can be summarized as such (See the subsections below for specific details about these changes): - the physics `kind` field is removed - the `long_name` field is changed to `description` - Several changes to particular terms and components of existing names have been made After this PR is merged, a `v1.0.0` tag will be created, representing the first true "versioned" version of the ESM Standard Names. While more rule changes are likely in the future to resolve open and future issues, this should be a more stable jumping-off point to allow updates and reconciliation with the names in the CCPP physics repository, which has not been resolved in many years now. For those who have not been following along with the discussion and changes related to the **v1** branch, here is a summary of each of the changes made on this branch: ### #85 First rules update, fixing misspelled standard names This first change introduced some changes to the Rules document based on discussion in the CCPP framework regular meetings. These rules changes can be summarized as follows - Introduced a more rigorous and standardized formula for constructing new standard names, with specific rules and definitions of each component of the name, attempting to cover all possible cases - Introduced the concept of "suffixes" to compliment prefixes, with mixing_ratio_wrt``_Y`` being the first example - Introduced the concept of "Reserved phrases"...for now only including "CCPP" as a reference to CCPP-specific variables In addition, a large number of misspellings within the existing names and rules were fixed. ### #87 Second rules update in v1 branch, update several name types This second change introduced the concept of "base names"; representing the main entity from which a standard name is constructed. Some existing prefixes (`surface_X` and `air_X`) were converted to suffixes (`X_at_surface` and `X_of_air`) to improve consistency with other existing names and rules, and some superfluous `surface` wording was removed from several names. The definitions for mixing ratios were improved, and the rules for constructing new names were updated and improved. ### #104 Add techincal specification, substitute abbreviations, include base name definitions This third rules change included some info about technical specifications of the standard names repository, and some formatting improvements. Instances of the term `weight` were changed to `scaling_factor` to avoid potential confusion with the physical property of weight. `long_name` descriptions were added for all the new "base names" with a few minor exceptions. Some new abbreviations were defined to help shorten names. Some unused and duplicate entries were removed. Finally, CCPP-specific variables were consolidated into their own section. ### #116 Rename long_name --> description, update description rules, expand list of abbreviations This fourth change renamed the `long_name` field to `description`, clarifying that this field should be unique, and improving/fixing some existing descriptions. Some more duplicate entries were removed. Some additional new abbreviations were defined to continue shortening names. Finally, continued defining more abbreviations to help shorten standard names further. ### #124 Remove `kind` entry, clarify rules for units and disallowed terms This fifth and final change to the v1 branch (aside from another PR to resolve intervening changes from the main branch) updated the rules to clarify disallowed terms and the role of `units`, and removed the `kind` entry. The `constants` section was organized alphabetically, and changed some names regarding `dry_air`. ## Issues Resolves - #48 - #68 - #94 - #102 Also reference already-closed issues: - #92 - #93 - #95 - #103 --------- Co-authored-by: Jesse Nusbaumer <nusbaume@ucar.edu> Co-authored-by: Dom Heinzeller <dom.heinzeller@icloud.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR addresses the following issues:
amountreplacing it with more specific terms where needed, and includes a new section on "disallowed terms" that includesspecific_humidityandamount.In addition, this PR organizes the "constants" section alphabetically, and replaces the too-specific
dry_air_densitybase name withdry_air, and changedry_air_densitytodensity_of_dry_airto better fit with naming conventions in the updated rules.Issues