-
Notifications
You must be signed in to change notification settings - Fork 64
CCPP Framework Meeting Minutes 2020 03 05
Dom Heinzeller edited this page Mar 5, 2020
·
3 revisions
Agenda
- No progress on moving towards
cap_gen.py
from Dom - Eliminate runtime reading of namelists in parameterizations
Runtime reading of namelists in parameterizations
- Host model to read namelists for parameterizations
- Augment metadata (see https://github.com/NCAR/ccpp-framework/wiki/CCPP-Framework-Meeting-Minutes-2020-01-30 for a proposal)
- This should only be applied to namelist variables - does the presence of
default_value
make it a namelist variable? Or addruntime_parameter = .true.
(redundant)? Maybe better to call itinit_default_value
for clarity? - Opportunity for the host model to define the value; if it is not found in the host model dictionary during init, then the CCPP framework will set it to the default value
- This should only be applied to namelist variables - does the presence of
- host model defines what type of namelist to use (json, Fortran namelist, ...)
- there is no scheme namelist any longer, all this information is part of the metadata
- standard names as keys in the host model namelist - one section per parameterization or a single section for CCPP?
Level of expensiveness of CCPP checking etc
- Do we need to define how expensive CCPP can/should be depending on the checking level (debug, info, ...)
CCPP NUOPC generator
- CISL has money to do some GPU work on CCPP (Steve to meet with them)
- Steve's project does not have a deliverable for the NUOPC cap prototype, but would like to do it
- What is discussed above (namelists etc) will help this effort
- Should we come up with a new proposal that includes the NOAA chemistry people to fund this work?
- note: CARMA microphysics package (which has chemistry aspects) will be implemented by NCAR, funded by NOAA
Blocked data structures in init/finalize routines
- substitute
ccpp_block_number
to with:
in auto-generated static caps? - Steve will create a test for this, we need to check that this is supported by all compilers
- this will cause problems: how to declare the dimensions in the variable declaration inside the subroutine
- better: use
horizontal_dimension
for_init
and_finalize
etc., the run routine useshorizontal_loop_extent
; the auto-generated cap will recast a variableA(:)%B(:,:,:)
toC(:,:,:)
where the horizontal dimension is set correctly