Adding some information on Standard Names for dimensions in metadata files#80
Adding some information on Standard Names for dimensions in metadata files#80
Conversation
mkavulich
requested review from
climbfuji,
grantfirl and
ligiabernardet
as code owners
mkavulich
force-pushed
the
add_dimensions_info
branch
from
c66d568 to
ac52226
Compare
| [dim_name]_begin:[dim_name]_end ==> 1:[dim_name]_loop_extent | ||
| [dim_name]_begin:[dim_name]_end ==> 1:[dim_name]_dimension |
There was a problem hiding this comment.
I know what you mean (because I wrote ccpp-prebuild), but for most people this will be confusing and scary. We need to explain that the left side (slices of the entire array allocated by the host model) in the CCPP run phase are sent to the CCPP physics scheme for parallel processing using OpenMP threading, and that schemes require the horizontal "dimension" for the current call to run from 1 to the length of the slice. I hope you can explain that better; some of it may already be explained in the next section (It is important to understand the difference between horizontal_dimension vs. horizontal_loop_extent), in which case we should refer to that section.
There was a problem hiding this comment.
Much of this text was pulled out of the "dimensions" comment of the Standard Names, since it shouldn't really be documented there anymore. But I admit I do not know much about how CCPP handles parallelization decomposition, except from what I've read in the documentation. I have tried to rephrase it better to the best of my understanding of how CCPP works, please let me know if the current version makes more sense or if you think it needs more work.
| but not in xxx_run routines. Currently, the only dimension which supports all | ||
| six dimension types is horizontal_dimension. |
There was a problem hiding this comment.
I don't really understand what you mean with the last sentence, but I don't it's correct and it should probably be removed.
There was a problem hiding this comment.
This was another phrase directly from the comments I pulled out of the Standard Names. I think the intention was to indicate that OpenMP parallelism is only broken down along the horizontal dimension, not other dimensions. Is this not correct?
… within each section (#140) ## Description This PR reorganizes the existing standard names (with no changes, except some updated descriptions) into a new section heirarchy that removes references to specific modeling systems (specifically GFS typedefs). The new sections are mostly descriptive of the way the variable is used, and I attempted to make the sections as generic as possible. With this type of natural language organization I believe it's impossible to unambiguously assign certain variables to certain sections, but I have attempted to keep things as organized as possible. The new sections are in bold below - Base names - Generic names - Chemical species - Base standard Names - Dimensions - Constants - Coordinates - **Timing** Variables defining or relating to timing, dates, calendar, and related concepts - **Atmospheric properties** - Marine - **Tracers** Tracers are numerically zero-mass particles advected in fluid flow, typically representing some trace gas, particle, or other physical substance - Atmospheric composition - **Gasses** - **Precipitation, cloud, and hydrometeor variables** - **Aerosols** - **Emissions** Emissions variables, contributed for the Community Emissions Data System (CEDS) - Application-specific variables - Required CCPP framework-provided variables - Optional CCPP framework-provided variables - System variables - **Control variables** Variables that indicate or control some action. - **Indices** Values indicating the index of some array or other data structure - **Coefficients** Coefficients includes scaling factors, tunable parameters, and other similar variables - **Thresholds** Thresholds represent some value at which the behavior of some process changes, including maximums and minimums - **Stochastic physics variables** - **Radiation** - **Atmospheric surface and boundary layer** - **Land surface, subsurface, and vegetation properties** - **Convective physics parameters** - **Gravity wave drag parameters** - **Tendencies** - **Chemistry processes** I am very open to feedback about changing these specific section names, so please review away. I tried to keep the sections as generic as possible, avoiding references to specific models or types of parameterization, but it wasn't always possible from my point of view. Within each section, standard names are now alphabetized to give a more logical and unambiguous sorting. This was accomplished with a new tool, `tools/sort_standard_names.py`, written by Claude Code running locally with `gpt-oss:20b`. I also added another Claude-Code-written tool, `tools/list_names.py`, that gives a monolithic alphabetized list of all standard names; I used this to ensure that no names were accidentally lost in the reorganization. I have thoroughly reviewed the Claude-generated scripts, and attest that I understand and approve of their functionality. I have integrated the alphabetization check into the GitHub CI, and added a rule about this alphabetization to the Rules document. Because the alphabetization is maintained by a tool, it does constrain the formatting and indentation of the XML. I believe this is a fine tradeoff, since the Metadata files are designed to be human-readable and it's a lesser concern for the XML. But I'm open to feedback on this. Finally, there was a lot of text in the comment of the Dimensions section that was specific to CCPP; I have removed this text and added it to the CCPP technical documentation (NCAR/ccpp-doc#80) ## Issues Resolves #135
2 participants
As part of the ESM Standard Names reorganization (PR incoming), I noticed a lot of CCPP-specific information about dimensions was stored there, that should more properly be located in the CCPP tech doc. This PR adds that information.