CCPP Framework Meeting Minutes 2020 06 04

Agenda

• blocked data structures
• active attribute, optional arguments
• multiple versions of physics schemes

Blocked data structures

• ccpp_prebuild.py now has the capability to pass blocked data structures to _init and _finalize routines
• this works with uniform and non-uniform block sizes, as well as with unit conversions
• this code is now in NOAA-GSD's gsd/develop branches and will come to EMC develop / NCAR master mid June(-ish)
• example from mp_thompson_init (without unit conversion)

        allocate(tmpvar14(1:GFS_Control%ncols,1:GFS_Control%levs))
        ib = 1
        do nb=1,GFS_Control%nblks
          tmpvar14(ib:ib+GFS_Control%blksz(nb)-1,:) = GFS_Data(nb)%Statein%tgrs
          ib = ib+GFS_Control%blksz(nb)
        end do

• having this capability allows us to introduce the timestep_init and timestep_finalize phases, move the code from the GFS_time_vary_*_run routines to the _timestep_init routines and get rid of the GFS DDTs in there
• ccpp_prebuild.py uses workarounds (called "legacy extensions") to deal with inconsistent use of horizontal_dimension and horizontal_loop_extent in the different phases --> needs to be cleaned up
• CCPP standard names currently used for handling this logic - should we change those, be more consistent, ...?

CCPP_BLOCK_NUMBER        = 'ccpp_block_number'
CCPP_BLOCK_COUNT         = 'ccpp_block_count'
CCPP_BLOCK_SIZES         = 'ccpp_block_sizes'
CCPP_THREAD_NUMBER       = 'ccpp_thread_number'

CCPP_HORIZONTAL_LOOP_EXTENT = 'horizontal_loop_extent'
CCPP_HORIZONTAL_DIMENSION   = 'horizontal_dimension'

• other CCPP standardd names used for subcycling, error handling, ...:

CCPP_ERROR_FLAG_VARIABLE = 'ccpp_error_flag'
CCPP_ERROR_MSG_VARIABLE  = 'ccpp_error_message'
CCPP_LOOP_COUNTER        = 'ccpp_loop_counter'

Active attribute, optional arguments

• new metadata attribute active was introduced that allows the host model to tell the code generator when an array is allocated and initialized properly, for example (from GFS_typedefs.meta):

[nwfa2d]
  standard_name = tendency_of_water_friendly_aerosols_at_surface
  long_name = instantaneous water-friendly sfc aerosol source
  units = kg-1 s-1
  dimensions = (horizontal_dimension)
  type = real
  kind = kind_phys
  active = (flag_for_microphysics_scheme == flag_for_thompson_microphysics_scheme .and. flag_for_aerosol_physics)

• code generator needs to know about this in order to perform operations such as handling blocked data structures, perform unit conversions, or perform debug checks etc.
• cap_gen.py has additional attributes that tell the framework if a variable is an allocatable array or a pointer; however, this doesn't provide all the information the code generator needs to decide whether to manipulate these arrays before/after calling a physics scheme. For example (qgrs is always allocated):

[qgrs(:,:,index_for_water_friendly_aerosols)]
  standard_name = water_friendly_aerosol_number_concentration
  long_name = number concentration of water-friendly aerosols
  units = kg-1
  dimensions = (horizontal_dimension,vertical_dimension)
  active = (index_for_water_friendly_aerosols > 0)
  type = real
  kind = kind_phys

• example for how this active attribute is used in the caps (default value for active is T/.true.):

      if ((GFS_Control%imp_physics == GFS_Control%imp_physics_thompson .and. GFS_Control%ltaerosol)) then
        allocate(tmpvar10(1:GFS_Control%ncols))
        ib = 1
        do nb=1,GFS_Control%nblks
          tmpvar10(ib:ib+GFS_Control%blksz(nb)-1) = GFS_Data(nb)%Coupling%nwfa2d
          ib = ib+GFS_Control%blksz(nb)
        end do
      end if

• the active attribute somewhat overlaps with or could be used to replace logic that otherwise uses optional arguments (if we decide to use active on the physics scheme side, too)
• lengthy discussion about optional arguments:
  • tricky to use with the CCPP framework, no good solution (yet)
  • currently used in a complicated way in ccpp_prebuild.py, we tell developers to stay away from them
  • when adding the Thompson MP physics (which uses the presence of optional arguments to decide whether the aerosol-aware version is to be used or not), Dom handled this logic using a flag in the CCPP entry point
  • should we simply disallow using optional arguments in CCPP entry points, and instead use flags?

Multiple versions of physics schemes

• combining different flavors of largely identical schemes (for example, GFS and HWRF versions of saSAS) into one scheme produces ugly code, may impact performance (it doesn't in any measurable amount for the saSAS example), and can give different results when aggressive compiler optimization is used
• having two seperate schemes isn't a good solution either
• template programming to generate different flavors is not something that physics developer will support
• discussion to be continued at next meeting