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 mentioned 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
  • Discussion around tracer arrays
    • UFS: "tracer_concentration" --> "tracer_array" (they are not all concentrations)
      • index_of_specific_humidity_in_tracer_concentration_array --> index_of_specific_humidity_in_tracer_array
    • Units are wrong in qgrs
      • units = mixed (or various), kg kg-1 is wrong
  • WRF splits tracer arrays into mixing ratio arrays, number concentration arrays, passive scalars; doesn't have the mixed tracer array that UFS has
    • Need meaningful standard names for each of these
  • Is a standard name for a tracer array meaningful? Should schemes ever try to access the entire array? Todo: - Clean up physics that do pass the entire array and indices, should pass constituents unless it's not necessary to know what is in the array (for example when doing vertical mixing on everything in the array, regardless of what is in there)
  • Constituent properties will help with these problems (knows whether something needs to be diffused or not, etc.)
  • Need to have a discussion on best practices for forming the various tracer arrays, this is a good time to do this

Other business

  • Cancel November 11 meeting (Veterans Day)
  • NCAR ccpp-framework README.md out of date (e.g., "... C functions calling Fortran routines."), needs updating
  • Handling constituent information originating from a physics scheme
    • Didn't get to it, discuss next time
  • Specifying a data source for an input variable (see below)
    • Steve will create an issue for this
    • In brief: CESM needs runtime data, we don't have a runtime data standard
      • Currently use an XML file that is separate from the CCPP metadata for physics runtime options
      • UFS uses a Fortran namelist, or hardcodes it in schemes
    • Particular need for gridded data (e.g. mountain topography for gravity wave drag, lat-lon ozone concentration, ...)
      • Scheme cant' read gridded data, because it doesn't need what the grid is
      • Host model shouldn't know about this requirement, because it is specific to the scheme
    • Metadata standard that tells the host model what data to read for a certain scheme
    • Would it make sense to extend this to other data (e.g. lookup tables for radiation etc)
      • Could ask host models should do that so that physics don't need to know how to read data (netCDF, PIO, ...)
  • Staff rotations:
    • Laurie retires Dec 10
    • Grant moved from NCAR/RAL to NOAA/GSL on Nov 9
    • Dom moves to JCSDA starting Nov 29 with a four-month ramp down plab

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