-
Notifications
You must be signed in to change notification settings - Fork 18
Merging "Release/v1" branch to main #129
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
base: main
Are you sure you want to change the base?
Conversation
…P#85) Co-authored-by: Jesse Nusbaumer <[email protected]>
…d_name_table.py` to allow for subsections (ESCOMP#87) This is the second round of proposed rules changes based on our ongoing discussion to make both rules and names as consistent as possible. Major updates include: ### Standard Names - New "base_names" section, with subsections - Convert instances of "surface_X" to "X_at_surface" - Convert some instances of "air_X" or "X_of_air" - Explicitly state what mass mixing ratios are with respect to in long_name - Convert "mixing_ratio" to "water_vapor_mixing_ratio_wrt_moist_air" - Convert "surface_albedo" to simply "albedo", "surface_roughness_length" to simply "roughness_length" ### Rules - Update construction template to include [non-instant time] and [non-current time], swap [at level] and [in medium] - More detailed description of transformations and how they can work on multiple base names - Add a few more transformations ### `write_standard_name_table.py` - Updated to allow sub-sections in the standard names list
…m main, substitute abbreviations, include base name definitions (ESCOMP#104) Here is the next round of proposed changes, resolving several open issues related to topics of discussion over the past several weeks: ## List of changes - Resolve ESCOMP#91: merge in latest relevant changes from the main branch - Resolve ESCOMP#92: Convert instances of `weight` to `scaling_factor` - Resolve ESCOMP#93: Expand on long_name descriptions for base names: this was done except for a few very obvious (e.g. `area`) and/or undefinable (e.g. `energy`) names, and a few more that I will open an issue for shortly - Resolve some items from ESCOMP#95: This PR was already becoming too large so I decided to save some of these for later There were also a few changes not covered by issues: - Added the start of a "Technical specifications" section of the rules, describing the technical details of the dictionary itself. This includes the restrictions previously discussed on including only ASCII characters (and only alphanumeric + `_` for standard_names themselves) - Removed references to specific deviations from the CF standard name rules, since we are far diverged at this point. - Added units to base_name entries where appropriate - Removed several duplicate name entries - Removed two generic names that do not exist in CF and are not used in any existing standard names (in this dictionary or CCPP) - data_mask - specific_eddy_kinetic_energy - Added an example "comment" entry as an example of how this attribute could be used (see the `mixing_ratio` entry) - Changed `air_potential_temperature` --> `potential_temperature_of_air` per our previous discussions about designating mediums except for variables like `air_temperature` that are in common use.
… `description`, expand list of abbreviations, update descriptions (ESCOMP#116) ## Description This PR attempts to address the following issues: - ESCOMP#95: Standardize and define more abbreviations used in standard_names - ESCOMP#103: renaming `long_name` --> `description` to avoid confusion with the `long_name` attribute in CCPP/CF conventions. In addition, this PR clarifies that the description field should be unique, and adds a check for this (using a re-written tools/check_xml_unique.py script with expanded functionality) ## Issues Resolves ESCOMP#93, ESCOMP#95, ESCOMP#103 --------- Co-authored-by: Jesse Nusbaumer <[email protected]> Co-authored-by: Dom Heinzeller <[email protected]>
…nits, remove `kind`, clarify disallowed terms (ESCOMP#124) ## Description This PR addresses the following issues: - ESCOMP#94 Include more information on the role of "units" - ESCOMP#102 Remove "kind" from standard name entries - Partially addresses ESCOMP#105: this PR removes the ambiguous term `amount` replacing it with more specific terms where needed, and includes a new section on "disallowed terms" that includes `specific_humidity` and `amount`. In addition, this PR organizes the "constants" section alphabetically, and replaces the too-specific `dry_air_density` base name with `dry_air`, and change `dry_air_density` to `density_of_dry_air` to better fit with naming conventions in the updated rules. ## Issues - Resolves ESCOMP#94 - Resolves ESCOMP#102
…P#127) This PR merges the latest commits from main, reconciling with recent rules/standards changes in this branch. After this is merged we can start the process of making this major merge back to main.
I thought this was achieved by ESCOMP#127 but apparently I missed some conflicts
…y don't show at all
climbfuji
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all your hard work on this and especially the excellent summary in the PR description.
gold2718
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a pretty clean update, thanks for all the hard work!
ff7a342 to
3744d77
Compare
f16638f to
96652d9
Compare
… there are actually two formulations of the Exner function and we need to be explicit about which is being used.
|
@climbfuji @gold2718 (also I think @nusbaume was involved in the initial discussion), I've uncovered an error in our previous changes to names involving the Exner function. In previous discussions, we renamed and a dimensionless formulation (which is most common in NWP applications) Therefore, I have reverted those changes and re-named our "exner function" variables back to "dimensionless exner function". I have kept "exner function" and "dimensionless exner function" as separate distinct base names with detailed definitions so that we don't run into any confusion about the definitions of these quantities going forward. On a side note, I have also started some ongoing discussion in the CCPP physics repository regarding some potential inconsistencies in how these variables are being used in the physics code. This may result in further necessary changes/additions to the existing standard names, though probably in a separate PR from this one. |
Description
This PR merges The
release/v1branch into themainbranch.The
release/v1branch was split off frommainabout 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):
kindfield is removedlong_namefield is changed todescriptionAfter this PR is merged, a
v1.0.0tag 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
_Ybeing the first exampleIn 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_Xandair_X) were converted to suffixes (X_at_surfaceandX_of_air) to improve consistency with other existing names and rules, and some superfluoussurfacewording 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
weightwere changed toscaling_factorto avoid potential confusion with the physical property of weight.long_namedescriptions 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_namefield todescription, 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
kindentry, clarify rules for units and disallowed termsThis 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 thekindentry. Theconstantssection was organized alphabetically, and changed some names regardingdry_air.Issues
Resolves
Also reference already-closed issues:
weighttoscaling_factorfor clarity #92long_nameattribute todescription#103