CCPP Framework Meeting Minutes 2021 10 28

Agenda

• Transition to capgen.py
• Dropping support for optional arguments
• Dictionary of standard names
• Other business

---

Transition to capgen.py

• Estimates of dedicated time needed to complete unification tasks added to GitHub issues
  • https://docs.google.com/spreadsheets/d/1u_yA9PyG9aVHMvlXDjmVIaxcgaKo2nR7NPVV2Kmw0Ck/edit#gid=0
• Could use help to write unit tests that will pass once new capgen features are implemented (e.g., blocked data, unit conversion)
• Refactor capgen PR: https://github.com/NCAR/ccpp-framework/pull/410

Dropping support for optional arguments

• Use flags to determine which branch to take in the code and whether to access certain variables (can be optional), instead of testing for presence
• Together with the active attribute and the extended usage of present in the Fortran 2008 standard, we do not need the optional attribute in the CCPP metadata
  • Section in Fortran 2008 standard: 12.5.2.12 (Argument presence and restrictions on arguments not present), in https://wg5-fortran.org/N1751-N1800/N1791.pdf page 299
• Fortran variables can still have the optional attribute (in the Fortran source code), presence of variable in CCPP metadata decides if the variable gets passed or not (i.e. at compile-time)
• Remove optional attribute from CCPP framework (ccpp_prebuild) and ccpp-physics metadata
  • https://github.com/NCAR/ccpp-framework/pull/408
  • https://github.com/NCAR/ccpp-physics/pull/763

Dictionary of standard names

• Bug fix PRs that should be merged: "janic" --> "janjic" (https://github.com/ESCOMP/CCPPStandardNames/pull/23)
• Inconsistent standard names for vertical dimensions for radiation (issue https://github.com/ESCOMP/CCPPStandardNames/issues/24)
  • As mentioned in https://github.com/NCAR/ccpp-framework/pull/410, the decorated vertical dimensions for radiation have not been discussed in the context of the framework metadata parser, but the framework needs to know about them to function correctly
  • The decorated vertical dimensions for radiation are listed in the variables section in https://github.com/ESCOMP/CCPPStandardNames, but not in the dimensions section
  • The rules for creating standard names list the decorator _for_radiation

Other business

• We were encouraged to submit a full proposal for the CCPP surface composites work for the JTTI internal funding opportunity. Proposal almost ready, will share when sent off
• We got negative feedback for our LOI for the NOFO WPO JTTI proposal, which included the following features:
  • finalize unification of CCPP framework between NOAA and NCAR
  • surface composites (redundant with the internal call)
  • single precision physics
• It is still possible to submit a full proposal, focus on single/half/mixed precision physics only?
  • At the last ICAM ESPCI meeting: single precision (or even half precision) and mixed precision seems to be of interest to everyone
• NRL has created a single precision physics version based on CCPP v5, currently battling a few NaNs, PR will be created soon
  • DTC will update the PR (which will be for v5) to the head of main
• From last week: We need a process to update the CCPP requirements (e.g. optional arguments, single precision, ...)
  • Does this committee have the authority? Not alone, because the CCPP requirements document contains framework, physics, host model aspects
  • CCPP physics governance group must be included (scheme point of contacts/codeowners) for physics
  • CCPP framework developer team for framework
  • UFS infrastructure team for host model? How about other models?
  • Ligia to bring this up at the next CCPP physics governance meeting, Dom at the next UFS infrastructure team meeting
  • From last week: In kind contributors should also have the right to comment on requirements, not only the funding agencies
  • References
    • https://dtcenter.org/community-code/common-community-physics-package-ccpp/requirements
    • https://dtcenter.org/sites/default/files/community-code/ccpp-requirements-may2018.pdf