-
Notifications
You must be signed in to change notification settings - Fork 64
CCPP Framework Meeting Minutes 2019 03 21
goldy edited this page Mar 9, 2020
·
3 revisions
Prepare for meeting with NUOPC team (Cecilia, Gerhard, Raffaele), Fri 03/22/2019
- discuss Steve's plan, how do we get there from where we are now
- discuss approach to constants
- from EMC visit: NUOPC field dictionary, are these standard names compatible with what we are using
- NUOPC cap doesn't have to be implemented right now, but the new framework scripts need to allow us to do that; maybe chemistry people have to take on this task (and bring in the funding)
- we better concentrate on improving the framework
Report on meeting with EMC
- remove redundancy between input.nml and suite definition file
- not clear whether the static build with multiple suites is good enough for EMC (switch physics in case the model is crashing, ...)
- new cap_gen will allow multi-suite static build
- question of timing whether we can "wait" for this or piggyback and implement it in ccpp_prebuild.py
Metadata converter:
- auto-conversion issue: how much to automate, how much to leave for the user (us!) to fix manually
- merge PR right now, then create a tag/branch for the actual conversion of the NEMSfv3gfs metadata later on ( maintenance branch that addresses and resolves some of the issues as part of the conversion instead of correcting it in the code beforehand)
CESM with GFS physics:
- did May's proposal get funded? Steve has some time in that process
- another proposal is floating around, too - we don't know from whom
- there is an interest to make GFS physics more portable, the time vary steps are a show stopper in this respect
- need capability to run over entire domain if data is on blocked data structure, this is supposed to come in the future
WRF/MPAS workshop, CESM workshop contributions?
- coordinate presentations?
ccpp-framework:
- support swapping out variables/dimensions with parameters, for example for computational performance
- support pointers? only implement if there is a reason for it
- add "don't use pointers in physics schemes" to CCPP requirements
- allocatable, intent(out) is not allowed in schemes: timestep or suite are in charge of allocating the data (depending on the persistence)
- WRF, MPAS and chemistry will be using the new cap_gen right from the beginning