CCPP Framework Meeting Minutes 2021 11 04

Agenda

• Transition to capgen.py
• Other business

---

Transition to capgen.py

• Do we need any special handling of vertical coordinates for radiation?
  • If so, what are the semantics?

Other business

• November 11 meeting?
• README out of date (e.g., "... C functions calling Fortran routines."), please update
• Missing standard names? https://github.com/ESCOMP/CCPPStandardNames/issues/25
• Handling constituent information originating from a physics scheme
• Specifying a data source for an input variable (see below)
• Staff rotations

---

Sometimes, a physics scheme will need gridded input data that is specific to the scheme. The host model needs to perform the input of this data but should not have to know about the field or its source. I propose adding metadata to a variable to facilitate this functionality.

The players:

• grid_field_data: The standard name of a field of gridded data
• filename_for_grid_field_data: The standard name of the file where grid_field_data can be located.
• fieldname_for_grid_field_data: An ordered, comma-separated list of possible fieldnames under which grid_field_data is stored in filename_for_grid_field_data.

The action:

• The semantics would be that filename_for_grid_field_data and fieldname_for_grid_field_data could be added to the metadata entry for grid_field_data. This would allow the host model to read this data.
• Of course, this begs the question of where filename_for_grid_field_data comes from since the host model also does not know about that. This field needs to be a runtime value. While the CCPP Framework committee has not been able to define any standard for runtime values, CESM does need a solution. If desired, I can outline our current thinking in a future meeting.
• A question is whether fieldname_for_grid_field_data should be a hard coded list of (NetCDF) field names or be another runtime value. Thoughts?