Skip to content

Standard Names Meeting Minutes 2024 10 31

Jump to bottom
Michael Kavulich edited this page Nov 7, 2024 · 6 revisions

Agenda

Attendees: Michael Kavulich, Mike W., Jordan Powers, Dom H., Courtney P., Jesse N., Dustin S., Nate Crossette

Standard Names governance

We should stand up a group containing at least one member from each group using (or considering using) Standard Names

  • NCAR/CGD
  • NOAA/DTC
  • JCSDA
  • NRL
  • ???

These members can meet bi-weekly as needed to discuss updates to the standard names, rules, and other Standard Names topics.

Do we need official guidelines on governance aside from the understanding that everyone gets a seat at the table if they wish? At the very least we need rules on PR reviews and merging

Standard Names rules

  1. We should decide which rules need updating and update them accordingly. Might be best to make a first pass before inviting a larger group to keep the discussion tight.
  • I had started a PR but I decided a Google doc is a much better place to iterate for a complex set of proposed changes (also allows for easier comments/discussion)
  • Standard Names Rules
  1. We should rename the repository to remove CCPP from the name
  • Seems like something more descriptive than "Standard Names" should be used
  1. Adopt a version numbering scheme to allow users of the standard names to reference a "frozen" standard rather than haphazardly updating
  1. Decide what units to support
  1. Decide what variables should and should not be standard names
  • Do not include "flag" variables (boolean)

  1. Should Standard Names include constants, or should this be a separate standard?

  2. Develop an automated script that generates the entire possible list based on specified rules and base names

GitHub issues/PRs

Standard names (issues, PRs, discussions)

Other issues needing discussion

Notes

Summary

  • Standard name rules
    • Differentiate “state_medium” vs “surrounding_medium”
    • Base name INCLUDES the state medium
      • Can EITHER be “<state_medium>_” OR “of<state_medium>”
      • But once we choose one, that’s it
  • We will accept PR #78 and discuss further (if necessary) in future branch
    • Where does the component (horizontal) go? Vs base name (air_streamfunction)?
      • Needs further discussion
    • Will tag this (v0.1?) so they can point to this for now and then work on v1.0 with the new rules (also should note this in the PR that things will change)
  • For the foreseeable future, we’ll switch between Framework and Standard names (every other meeting)
  • Dom - would like people to think about issue #79

Full Discussion

  • Nate: Updating names on their end to match what’s in the dictionary and what’s in the PR (#78) & it would be very inconvenient to have to change them again
  • Michael K: started Google doc to edit rules/names
    • Proposes having list of base names that we start with
  • Jesse: would be beneficial to generate the whole markdown list based on base names and what prefixes/suffixes are allowed for each
    • Michael K - would be a very large list (might be ok, but is something to think about)
    • Courtney - full list being available would be useful for validating models’ use of names vs the dictionary to help w/ compliance
  • Dustin - would “air_temperature” be a base name vs “temperature”?
    • Michael K - yes, because it’s kind of an exception (otherwise it might be “temperature_of_air” or something)
    • Dom - would prefer base names not include things like “air” (later backs off of this)
    • Dom - Need to differentiate between “medium” and “in medium” (“air_temperature” vs “temperature_of_air”)
      • Nate - first medium is “state” medium and then “in medium” is the other medium
      • Tricky to word!
    • Nate - temperature/pressure seem like clear base names, what about Dom’s example of cumulative energy flux?
      • Michael K - flux is an “adjustment”
      • Courtney - maybe “cumulative_energy_flux” IS the base name?
    • Dom - could do away with “state” medium being separate from the base name - “medium” only refers to the thing it’s embedded in
      • Jesse: first medium is “what it is” and second medium is “where it is”
      • Jesse: proposes “core_medium” vs “surrounding_medium” (“state_medium”?)
        • And the “core_medium” is part of the base name
    • Jordan - what would you do with something like “sea_surface_temperature”? “Temperature_at_sea_surface”?
      • Michael K - would be same as air_temperature, perhaps. Keep the common usage ones but allow for construction of weirder names
      • Dom - If we want to be able to honor existing names in the community, we could translate things in the framework (of_air vs air, etc)
        • Michael K - seems like there’s ambiguity in this translation given how many potential translations there will be
          • Dom - proposal - can either have first medium as part of base name or “of_”
    • Dustin - we’re still going to have exceptions to the rules, which is a whole rabbit hole
    • Michael K - some names don’t fully convey meaning of what it’s describing; need to establish a “good enough” and as long as it’s unique, we can use the long name
    • Might not be ideal for JCSDA (using the names directly in the code), but the situations would hopefully be rare
    • Variable example: “air_pressure_thickness_of_dry_air”
      • “dry_air_pressure” or “pressure_of_dry_air”? What even is “air pressure thickness”?
    • Dom - base name INCLUDES the state medium
      • Can EITHER be “medium_name” or “name_of_medium”
      • Once we establish one, that’s what it is though
  • Dom - should see if we can apply these new rules to the existing names without everything spiraling out of control (to avoid having models update twice)
  • Versioning standard names
    • Michael K - allows for gradual evolution (remove urgency of component updates)

Gchat discussion:

You 9:31 AM https://github.com/ESCOMP/CCPPStandardNames/wiki/Standard-Names-Meeting-Minutes-2024-10-31 keep Pinned You 9:35 AM https://docs.google.com/document/d/19VOPWYA6RrFpeLZokmO-wSOLW6qQvZ_t2djDE4HZQoQ/edit?tab=t.0 Jesse Nusbaumer 9:44 AM yeah no matter what there will always be exceptions I think if we can just get most of the names will rule-based constructs and then just have the "outlier" list it would be beneficial Dustin Swales - NOAA Federal 9:45 AM agreed Dustin Swales - NOAA Federal 9:53 AM energy/heat/momentum flux Nate Crossette 9:55 AM Agreed with Courtney, because my feeling was that the energy flux name might make more sense being something like "cumulative_total_energy_flux_at_boundary" Jesse Nusbaumer 10:07 AM should we just add descriptions for them? For example "core_medium" and "surrouding_medium", and then describe what those two different media are? Courtney Peverley 10:07 AM i like "surrounding_medium" for sure! Dom Heinzeller 10:09 AM the more I hear, the more I tend to agree with Mike K that the "state medium" needs to be part of the base name Nate Crossette 10:10 AM actually, BTW, I'm wrong, velocity is a 'state medium' Dom Heinzeller 10:11 AM in this case, either dry_air_pressure or pressure_of_dry_air Jesse Nusbaumer 10:12 AM I am pretty sure it is supposed to be delta-p for a given model layer Dustin Swales - NOAA Federal 10:13 AM ^This Jordan Powers 10:19 AM Ah. Sounds like the term is for other contexts than synoptic analysis. OK. Nate Crossette 10:23 AM I'm going to need to drop off for another meeting. Thanks for including me! Jesse Nusbaumer 10:25 AM That's a good point, flip it to horizontal_air_streamfunction?

Clone this wiki locally