Skip to content

CCPP Framework Meeting Minutes 2024 02 26

Jump to bottom
Courtney Peverley edited this page Feb 26, 2024 · 7 revisions

Agenda

Attendees: Mike Kavulich, Grant Firl, Jesse Nusbaumer, Lulin Xue, Ligia Bernardet, Michael Waxmonsky, Dustin Swales, Dom Heinzeller, Cheryl Craig, Courtney Peverley

First item: need a note-taker

  • Not a permanent position, can rotate

GitHub issues/PRs

CCPP Framework (issues, PRs, discussions)

Standard names (issues, PRs, discussions)

New items for discussion

Standard names

  • Should units control what kind of mixing ratio (volume, mass, number concentration) it is as opposed to the standard name?
  • How should moist/dry/wet mixing ratio property be set? How can we make sure this works properly with variable standard names? Currently this property is set based off the standard name itself, although the actual names being used are out-of-date: https://github.com/peverwhee/ccpp-framework/blob/add_const_interface/src/ccpp_constituent_prop_mod.F90#L421
  • Should moist/dry/wet be controlled by standard name, or by metadata property [like "advected"] (which the constituents property object is carrying around anyways)? Also should there not be a default value (to make sure the property is always set)?
  • What units do we want to support for unit conversion?

CCPP version 7 release

  • CCPP stand-alone v7 release planned for ~June 2024
  • Any specific changes that we'd like to target prior to this release?

Timelines for PR reviews

Updates from last time

Previous notes

Other business

Meeting notes

  • Framework PRs
    • MPI (PR 523): plan to have the framework require MPI (2008); one detail to be ironed out (cmake file language)
      • needs CI testing addressed
      • related physics PR #160: makes it work with UFS; needs follow-up PR to clean-up remaining ifdefs
        • can be merged once framework one is merged
    • Optional metadata attribute (PR #529)
      • Dustin to address Courtney's comments
    • Clean-up/fix prebuild CI tests - MERGED
    • PR for dummy_allocate_inactive
      • Have fix in place for RFS implementation; optional argument solution will supersede this fix
  • Framework Issues
    • Create tests for optional attribute (#527) - can be closed (PR has been merged)
      • Just for capgen (goes with PR #529)
      • Will have to implement optional attribute and testing in prebuild before unification
        • Dom to tackle making the issue(s) and tackle the implementation
  • Standard Names
    • Jesse's PR approved by Michael K and Grant - ready to merge
    • feedback on meaning of sea_ice_area_fraction_of_sea_area_fraction
      • replacement suggestion from Met Office
      • how do we better clarify what the names mean? What additional documentation do we need/want?
        • Jesse - could long name contain additional information/context
      • Michael K to follow up
    • should units determine what type of mixing ratio we have?
      • Dustin likes the idea, but we need to make sure different units for the same quantity are handled (how will we handle this?)
    • should we have a property for moist/dry/wet (vs parsing from standard name)
      • Cheryl - goal should be you could have the same standard name with two different properties
      • Dustin - seems possible, but things will get complicated (these are more derived transformations - need additional information)
        • concern that these transformations are doing a lot and will lead to users doing weird things
      • Dom - should keep in mind the meaning of the standard name; two entities should only have the same standard name if they are the same physical quantity
      • Grant - we had previously discussed variable "families" - is that a can of worms we wish to open?
      • Cheryl - concerned with constituent properties - standard name is the same even if advected?
      • Jesse - chemistry will add 100s of new variables
      • Jesse - can always have constituent properties subsetted and the suite can do the actual conversions
      • Dom - what are our priorities? If we want to focus on unification; we should hold off on major changes to capgen
      • would be backward-compatible
      • Courtney to open an issue for further discussion
  • What units do we want to support?
    • Dustin - can put any unit conversions in the framework we want - if it's a "valid" unit no reason not to use it
    • Michael W - are we writing the math ourselves for these conversions? Yes. It's not super costly in terms of time to do these.
      • may want to consider third party libraries (Michael K agrees)
    • Cheryl - can tell users to open an issue for a new converter and we decide whether we want that (users themselves to implement)
    • Jesse - derived SI units? Joule vs Newton-meter, etc. This could spin out of control.
    • Dustin - can add a module for compatible units (equivalent units that have different representations)
    • Courtney to open an issue
  • CCPP stand-alone version 7 release (~Jun2024) feature requests/wish list
    • won't include capgen
    • Dom - stand-alone is SCM, right? Yes.
    • Dustin - optional attribute should open us up for a lot of cleanup - is that something we want to tackle?
      • Could get MPI cleanup and optional attribute into prebuild (and then start on cleanup) for release
    • Dom - chunked arrays vs blocked data (getting close in development)
    • Michael K to open an issue to track items for release
  • PR Review timeline
    • no push-back on proposed timeline
    • Courtney - sometimes helpful to have someone do a first pass before the masses
    • Dustin not likely to look at the Project page option
  • SEWG meeting next week - will cancel this meeting; next meeting 3/11

CCPP Framework wiki

Clone this wiki locally