-
Notifications
You must be signed in to change notification settings - Fork 64
CCPP Framework Meeting Minutes 2021 08 10
Dom Heinzeller edited this page Aug 10, 2021
·
13 revisions
- Development of computational performance evaluation testing
- GNU-10 compatibility
- Update on standard names
- Transition to capgen.py
- 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 much stricter w.r.t. argument mismatches, so far we had to add compiler flags to turn them into warnings (bad)
-
use mpi
orinclude mpif.h
don't work w/o these flags; need to useuse 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
-
- Rules for standard names PRs https://github.com/ESCOMP/CCPPStandardNames/pull/14 and https://github.com/ESCOMP/CCPPStandardNames/pull/16 merged
- Host model PRs:
- ccpp-physics: https://github.com/NCAR/ccpp-physics/pull/687 - merged
- UFS/fv3atm: https://github.com/NOAA-EMC/fv3atm/pull/337 - merged
- SCM: https://github.com/NCAR/ccpp-scm/pull/269 - not yet merged
- 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
- How should this be called?
- 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
- 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
- Dom started to update
feature/capgen
frommain
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
- ...