Skip to content

CCPP Framework Meeting Minutes 2021 11 04

Jump to bottom
Dom Heinzeller edited this page Nov 4, 2021 · 12 revisions

Agenda

Transition to capgen.py

  • Optional arguments have been removed from main (ccpp_prebuild scripts and all physics schemes)
  • Do we need any special handling of vertical coordinates for radiation?
  • Maybe no special handling needed for vertical dimension
    • No problem for transformations (permutations)
    • But how about flipping? We don't have a standard for what is top and what is bottom
      • Vertical preference could be in the table-properties section to enable flipping
    • Alterrnative I-don't-care-approach for physics (scheme works it out by itself)
  • Naming inconsistency mentionedd by Dom should be fixed, but no need to worry about extra vertical dimensions in capgen for now

Dictionary of standard names

  • After combined PR that removed optional arguments and fixed janic -> janjic, create tag (v0.1.1) and add reference to top-level README.md in ccpp-physics main
    • While we are at it, update NCAR ccpp-physics main README.md
  • Missing standard names? https://github.com/ESCOMP/CCPPStandardNames/issues/25
    • ...

Other business

  • November 11 meeting?
  • README out of date (e.g., "... C functions calling Fortran routines."), please update
  • 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?

CCPP Framework wiki

Clone this wiki locally