CCPP Framework Meeting Minutes 2019 06 06

What about schemes that have _init and _finalize, but no _run?

• separate "init" group?
• decorate the scheme in the SDF, e.g. ...
• or keep it the current way which implies that every scheme has all required subroutines (even if they are empty)
• looks like what we are doing now (incl. being able to call init for a group explicitly) works best for all
• but what if the order that schemes run in the init phase is different from the run sequence?
  • can an initializer depend on the order?
  • put dependency in the metadata table?

[ccpp]
name=foo_init
depends=bar_init

• ...
  • that would mean that ccpp-framework needs a dependency maker, not transparent to the user either
  • agreed going back to adding a special init or finalize phase that allows to reorder schemes (then the usual sequence will be ignored in the init phase, i.e. going through the inits of the run sequence is skipped)
  • this will NOT be implemented in CCPP prebuild

Groups in SDF:

• only the five standard groups init, timestep_init, run, timestep_final(ize), final(ize)
• won't work for WRF and MPAS, where some physics are called in other parts of the dynamical core
• that's why we have the suites in the host model repository at the moment
• how are we going to do this in the future, i.e. how are we going to capture host-model specific information in SDFs
• review/explanation of the five phases init, timestep_init, run, timestep_finalize, finalize
  • keep all five, and every scheme needs to have all of them (empty if not used)
  • CCPP prebuild / cap_gen will err out if not found

Side note on explicit arguments for all function calls as it is done by CCPP_prebuild:

• limit on number of continuation lines?
• Fortran 95: 39, Fortran 2003+: 255; Intel allows more, and even with F95 standards flag GNU and Intel just spit out warnings and don't abort (but we don't want to rely on this)

Can we just ignore case in standard names? (Steve)

• CF convention says standard names are case-insensitive
• should we be case-insensitive but preserve it (for eventual diagnostic output)? --> yes

Thoughts on standard name methodology (Dave)

• special characters in standard names?
  • we are not really supportive of this idea
  • long name can hold all this information?
  • has the long name to be consistent?
  • it is not checked by the prebuild script, but it seems desirable that people are using the same long names
  • right now FV3 uses some "generic" variables/containers for different information, depending on which schemes are run, we use different long names inside the physics schemes to describe these better
• What is the governance for the rules constructing standard names, the superset of names, ...?
  • NUOPC won't be ready anytime in the near future to work with us
  • we need to work on our own to come up with the library of standard names

Host model configuration of threading model (Steve)

• should we document what the host's threading model is, for example in the host model metadata?
• for example, which variables change in threaded/non-threaded blocks
• which variables are used to define the threads
• Steve will prepare something to discuss in one of the next meetings

No CCPP framework meeting on June 13 (WRF workshop).