CCPP Framework Meeting Minutes 2025 01 09

Agenda

• GitHub issues/PRs
• New items
• Updates
• Other business
• notes

---

Attendees: Dom Heinzeller, Jesse Nusbaumer, Michael Kavulich, Cheryl Craig, Jordan Powers, Courtney Peverley, Michael Waxmonsky, RhaeSung Kim

GitHub issues/PRs

CCPP Framework (issues, PRs, discussions)

• Add support and testing for equivalent units #571

  • Open for review, take a look!

• New checks/update getter for molar_mass in constituents object #620

• Enable multiple schemes to use the same local name for different variables #621

  • Some more discussion after last week

• Constituent index lookup #622

• Bugfix for variables in multiple groups #618

Drafts

• Testing refactor #612

Standard names (issues, PRs, discussions)

• add emissions names #86

  • Still needs fixes to markdown vs xml, will ping

• Second rules update in v1 branch, update names, update write_standard_name_table.py to allow for subsections #87

  • PR to release/v1 branch
  • Will address comments

New items for discussion

Updates from last time

Previous notes

Other business

Offer suggestions/comments on development workflow rules:

• https://docs.google.com/document/d/1iMh_iKsUrB_mOMF6lGkFggG85JV62NFkTjKJboqWvV8/edit?tab=t.0

Meeting notes

CCPP Framework

• Add support and testing for equivalent units (#571)
  • Open for review
• Enable multiple schemes to use the same local names (#621)
  • Courtney to find a smaller example that fails in the unit tests
• Constituent index lookup (#622)
  • Ready for review
• Testing refactor draft (#612) - no updates
• Courtney to make an issue to address problems with non-standard indexing

Standard Names

• Add emissions names (#86)
  • Needs to modify XML file
  • Cheryl pinged the ACOM scientists - they don’t expect to use standard names for their emissions; don’t care about these names (for now)
• Second rules update (#87)
  • PR to release/v1 branch
  • Michael K will address comments

Discussion

• Offer discussion on development workflow rules!
• CCPP MPI interface (#1106 in ccpp-physics)
  • NCAR folks are trying to avoid using MPI in the physics entirely
  • Another option - define MPI_KIND_PHYS that abstracts that if logic away
    • Still have error handling
  • Not required
  • Michael W working on a data reader (but won’t be ready very soon) that will resolve some of these issues - will just need to call the API to read in a file; will choose an appropriate method supplied by the host model
    • Might still need straight MPI for “uncommon” data types
  • Jesse - wrapping other MPI methods?
    • Dom - just broadcast
  • General agreement that we’re ok with bringing it into the framework
  • Dom to open issue in framework