Skip to content

CCPP Framework Meeting Minutes 2021 08 10

Dom Heinzeller edited this page Aug 10, 2021 · 13 revisions

Agenda

New business

  • Development of computational performance evaluation testing

Old business

  • GNU-10 compatibility
  • Update on standard names
  • Transition to capgen.py

Development of computational performance evaluation testing

  • Part of Hurricane Supplemental project at NCAR, software testing for ccpp-framework: unit testing, functional testing, computational performance testing
  • Limited resources left on this project
  • Use existing functional testing and add basic timing/memory testing to it? Other ideas?
    • Instead of using SCM model and data, create a stub model?
    • Goal: assess computational performance of framework, not physics
    • In most cases, single column testing is fine, exceptions: blocked data structures that need to be copied into contiguous arrays and back, and MPI broadcasting at physics init time
    • Run-to-run variability can make it hard to detect actual changes in the performance
    • Can this be used to also test the performance of the physics (which change much more often than the framework)?
    • Stub suite with only one stub scheme that exercises the relevant parts of the framework (with/without unit conversions, with/without blocking/deblocking data, ...)
    • SCM already has a timing utility in the run scripts (can use N iterations to smooth out some of the machine variability)
    • Possible to integrate with regression testing framework of ufs-weather-model

GNU-10 compatibility

  • GNU 10 much stricter w.r.t. argument mismatches, so far we had to add compiler flags to turn them into warnings (bad)
    • use mpi or include mpif.h don't work w/o these flags; need to use use mpi_f08
    • This turns the MPI communicator into a DDT (no longer an integer), does the framework support this w/o a definition of the DDT?
      • Tell capgen (via command line argument, for example) which MPI standard to use and then provide the DDT metadata information as required
    • Does use mpi_f08 work with all systems that need to be supported
      • No, it doesn't - but it is on the agenda to roll it out to the community

Dictionary of standard names

  • Rules for standard names PRs https://github.com/ESCOMP/CCPPStandardNames/pull/14 and https://github.com/ESCOMP/CCPPStandardNames/pull/16 merged
  • Host model PRs:
  • Need to update https://github.com/ESCOMP/CCPPStandardNames/pull/13 based on PR 16 and create follow-up PRs for ccpp-physics, fv3atm, scm
  • Open discussion points:
    • Tracer array versus constituent array: NOAA and NCAR models have several components in one array, e.g. mixing ratios, number concentrations, cloud fraction, TKE, ... - not all of these are to be advected by the dycore
      • How should this be called? tracer is not correct, because tracers are by definition advected
    • Host-specific variables: Some standard names in the ESCOMP PR 13 are specific to FV3, should they be part of the dictionary?
      • Use different branches or repositories, or metadata associated with a variable?
    • Two reasons for the dictionary:
      • Interoperability (that is, should not contain host-model specific names)
      • Resource for developers to look up existing names (should contain host-model specific names)
    • Create a dictionary with a set of common names (that are host-model independent), and then have the capability to select a host-model specific superset?
      • Start out with the generic/minimal dictionary?
      • Or, add the host-model specific variable in a separate category (e.g. UFS) for now?
      • Clarification of some of the standard names may be helpful, for example replace flag_for with something clearer

Transition to capgen.py

  • Dom started to update feature/capgen from main to simplify future work and merge back
  • Code now compiles, need to run regression tests, then update main and send updates back to feature/capgen

Other business

  • ...
Clone this wiki locally