Skip to content

CCPP Framework Meeting Minutes 2024 08 15

Jump to bottom
Michael Kavulich edited this page Aug 15, 2024 · 4 revisions

Agenda

Attendees: Mike Kavulich,

GitHub issues/PRs

CCPP Framework (issues, PRs, discussions)

Standard names (issues, PRs, discussions)

New items for discussion

  1. Because we're now targeting develop instead of main, issues that are mentioned in PRs are not automatically closed when the PR is merged. Should we:
    • Wait until the PR is being merged into main, at which time we'll add ALL the issues addressed
    • Close issues manually
    • Create an automatic PR closing workflow for PRs targeting develop

Updates from last time

Previous notes

  • How to handle approvals from NEPTUNE?

Other business

Meeting notes

CCPP Framework

  • Diagnostic object
    • Diagnostics = fields that either aren’t output to host model or we want to capture a field during the course of a physics scheme
    • Dustin is in for a diagnostics object in general
    • Dom
      • Similar to prebuild ccpp data object that is passed around
      • Hashable character
        • Use existing fortran dictionaries that resemble python dictionaries instead
      • Needs to be optional / not break pre-build
    • Grant - use metadata attribute to ID diagnostic; what needs to be different about a diagnostic variable?
      • Jesse - from CAM’s standpoint, there are a lot of diagnostic variables that will inflate the calling list
    • Dustin - is this kosher with the CCPP philosophy? Where we’re supposed to have everything in the argument list?
      • Grant - don’t want to hide the individual diagnostic variables and their units
      • Courtney - can keep metadata similar to constituents object, indicates to framework to add to diagnostics object
    • Dustin - diagnostics instead are just optional?
      • CAM SEs to discuss leveraging optional arguments for diagnostics
      • Dom agrees that optional would be a simpler option
      • Cheryl - still need “diagnostic” metadata attribute?
        • Michael K - what about schemes that use fields diagnostically, and some that use that field non-diagnostically?
        • Dom - shouldn’t need to ID something as diagnostic since that only matters to the host model?
  • ccpp_track_variables broken (#580)
    • Target main or develop?
      • SCM can use hash of develop branch?
        • Dustin - doesn’t know if that’s OK
      • Dustin - don’t have to go to develop first?
        • Michael K - going to develop first is in the spirit of the current documentation
        • Jesse - prefers develop first so things don’t get out of sync
        • Dom - also prefers develop first; also, can create release branch from main and cherry pick the develop commit
          • Michael K - yep. That seems like the ideal path forward
  • Register phase (#582)
    • People to look at PR & comment offline

Standard Names

  • Nothing new

Discussion

  • Issue closing - when to close?
    • Michael K - issues closed after develop sounds right
    • Michael K - manually closing seems doable
      • Mentioning the issue in the main PR would be second line of defense
    • Dom & Michael K - issues that need to be in main, you’d probably be tracking that in the host model
    • Michael K to add to development rules that issues should be closed manually
  • People should look at the development documentation
  • NEPTUNE approvals - Dom is only one, so there’s no backup
    • Dom - no one else works on the framework, so maybe no backup there…
      • No approval needed for PRs to develop if Dom’s not there
      • Will need backup for running regression tests though!
    • But ccpp-physics will have a backup
  • Dom’s merging thoughts (based on previous notes)
    • Squash and merge
    • Works for feature branches to develop, but should do regular merge for main or release branch

Meeting chat: Grant Firl - NOAA Affiliate 9:56 AM Agree that that assumption can't be made Grant Firl - NOAA Affiliate 9:58 AM That's a good point. mass fluxes are an example in UFS -- used to be purely diagnostic, then other schemes wanted to use them. Dustin Swales - NOAA Federal 9:58 AM Along these lines... If we ever move to the framework doing process/time split (e.g handling the state evolution), we are going to need a "state_varaible" attribute in the future as well Dustin Swales - NOAA Federal 10:16 AM I'll bring my ice pick Dom Heinzeller 10:17 AM and I bring a box of blue bell You 10:17 AM https://docs.google.com/document/d/1iMh_iKsUrB_mOMF6lGkFggG85JV62NFkTjKJboqWvV8/edit Courtney Peverley 10:18 AM https://github.com/NCAR/ccpp-framework/wiki/CCPP-Framework-Meeting-Minutes-2024-07-18

CCPP Framework wiki

Clone this wiki locally