-
Notifications
You must be signed in to change notification settings - Fork 67
CCPP Framework Meeting Minutes 2025 12 04
The following notes are from Dustin, tweaked by Dom and Steve
We (Dustin and Courney) will modify Capgen to pass the "parent" Host fields to the Suite Cap, as is done in Prebuild. More details while they are fresh: During the analyze phase, where Capgen creates the Suite call-lists, construct call-lists using the Host DDTs and flat-fields (e.g. VarDDT), instead of using each sub-field (e.g. VarDDT%Var1,...,VarDDT%VarN). Then later when creating the Scheme call-lists, use the full call-string (e.g. VarDDT%Var1), instead of the Group call-string (e.g. Var1). Additionally, modify the pre/post Scheme actions (e.g. var1_ptr => Var1) to use the full call string (e.g. var1_ptr => VarDDT%Var1). On a somewhat related note, OpenMP threading information needs to be accessible within the Suite Caps in order to create thread safe local Group variables.
The Navy requires support for multiple instances of the CCPP physics within the same MPI task. To accommodate, Capgen needs to be able to do two things: a) pass information on the host model instance into the Suite Cap and b) Allocate any Suite variables by number of instances.
Dom proposed using the Fortran formatter Codee. These tools do exactly as their name suggests, take an input Fortran source file and provide a re-formatted file. The "free-format" version of Codee is free, whereas the "fixed-format" is not. This is easy to setup in CI, and Dom volunteered to give it a try. Ultimately, we could use this formatter on our auto-generated code, and possibly with a tighter integration with Capgen (parse codee config to obtain information on formatting rules).
We also discussed python code formatters. Black was mentioned as a well known option, which is often used in conjunction with linters such as flake8 and isort. Ruff was brought up as an alternative for the three utilities, and Dom was tasked to check with the spack developers (spack uses black, flake8, isort at the moment) on their thoughts about these tools.
It was agreed upon that maintaining two branches is not practical and is moreso a relic of a previous code management requirement. The main branch will be frozen and all hosts who wish to update their framework hash will switch to referencing a hash on the develop branch going forward. We will also revisit the tag naming convention and update the wiki accordingly.
The codebase could be more modularized and would benefit from some housekeeping after we (SCM/UFS/NEPTUNE) transition to Capgen. There will probably be optimizations that need to occur, at which point we could tackle some refactoring if necessary.
We plan to document and enforce (Mike K.) our code review procedures. All participating "Teams" will need to respond to reviews within 2 weeks, otherwise we will assume implicit approval and merge the PR. We currently have 4 Teams that need to approve each PR into develop. Each Team consists of 1-2 people, so using Teams may be overkill, but the idea is that each Team corresponds to a host model institution (NOAA: Dustin/Mike K, NAVY: Dom, NCAR: Courtney/Jesse, NOR: Steve G). GitHub CODEOWNERS could be modified to facilitate this in the code review process (Mike K has already got this started!).