-
Notifications
You must be signed in to change notification settings - Fork 64
CCPP Framework Meeting Minutes 2024 10 10
Courtney Peverley edited this page Oct 10, 2024
·
4 revisions
Reporting to you live from FL1-2198!
Attendees: Mike Kavulich,
CCPP Framework (issues, PRs, discussions)
-
Add CCPP register phase PR#582
- Ready for review!
-
Add constituent tendency capability PR#584
- Newly updated!
-
Amend offline_check_fortran_vs_metadata.py to log what it has checked Issue#592
-
Unit conversion bug when variable is used by two different schemes (with different units) Issue#594
-
Related issue in Prebuild: Unit conversion bug in ccpp_prebuild.py: variables that are slices of a n+1 dimensional array have wrong allocation #598
-
Make full constituents object available via metadata Issue#597
-
- Conclusion: not a bug, but documentation needs updating (https://github.com/NCAR/ccpp-doc/pull/74)
Standard names (issues, PRs, discussions)
- How to handle schemes that are called multiple times, but with different inputs?
- One possible solution: syntax like
<scheme name_of_fruit="orange">eat_fruit</scheme>
and<scheme name_of_fruit="apple">eat_fruit</scheme>
- One possible solution: syntax like
- Tagging standard names - Haipeng demo
CCPP Framework
- Expanded/enhanced testing issue
- Dom - anyone have python Mock experience?
- Michael W has some
- kind_phys bug
- By design, it behaves as expected (Dom has updated the documentation; Michael K to approve it)
- Reconciliation from production/RRFS.v1 branch to main (Grant)
- Grant will close this; Dom has answered his question
- Was a temporary solution for “check all” flag
Standard Names
- Reconsideration of “Add four wind CF variables #73” (issue #77)
- Raises issues of inconsistencies
- Dom - were planning to discuss broader use of CCPP standard names at SAICCT meeting, but ran out of time; will do it next meeting
- Neptune folks and JEDI folks are amenable
-
Will need to establish clearer governance, be faster with review for this to work
- Want to minimize impacts to source code
- Unclear if there’s DTC funding for governance of standard names
- Grant - previously discussed bringing in CF folks to see if they want to expand their standard - should we revisit that?
- Michael W - want to have some of these external conversations sooner rather than later (plus maybe renaming the repo now vs later)
- Also - improve user friendliness of standard names
- Also need to nail down things like what the long name is vs standard name
- Grant - need automated tests to cross-check
- Questions as to where the tests should exist, but problems are solvable
- Dom - dictionary provides API to check validity of name?
Discussion
- Haipeng: improve usability/findability of standard names
- Tags (groups/categories/process) would make things easier to find/search
- Can also consolidate variable variations (like “tendency_of”, etc)
- Michael K - in prebuild, we have a track_variables.py script
- Could also hopefully be leveraged in capgen
- Dom - should define what kinds of tools should come with standard names repository
- Could then leverage those from various other repos
- Jesse - real database structure with searching functionality would be nice
- Haipeng - standard names houses standard API/base documentation to be expanded by host models
- Dom - harkens back to R2D2 database on where input/output files live
- SQL DB that sits on AWS server; REST API to access
- Could do something like that and have server that people could query w/o checking out the database
- Could leverage their expertise for this
- Brian Dobbins - would it make more sense to change to suffixes to improve organization? (all “air_temperature” variables would be grouped together alphabetically)
- Michael K - should decide what kind of variable gets a standard name (e.g. a flag for a specific mode of a physics scheme)
- Brian D - also should see if we could stay as close to “first principles” as possible (e.g. instead of a variable like ratio_of_X_to_Y, pass in ‘X’ and ‘Y’ and calculate the ratio in the scheme)
- Jesse - we can switch atmospheric_physics to a fork of ccpp-physics
- Cheryl - should organize in a way that we can grab what we need and exclude what we don’t need
- Michael K - submodules have been discussed with other dycores as well
- Dom - ~10 different versions of RRTMG - it’s not easy to unify across models
- Grant - developers should do a better job of silo-ing the parts of the schemes that may need to change between hosts
- Cheryl - should organize in a way that we can grab what we need and exclude what we don’t need