-
Notifications
You must be signed in to change notification settings - Fork 64
CCPP Framework Meeting Minutes 2019 08 22
Dom Heinzeller edited this page Aug 22, 2019
·
20 revisions
Updates:
- Steve wrote a new tool that analyzes a Fortran file and creates a prototype of the metadata file
WRF-MPAS-GFS physics interoperability:
- both WRF-MPAS and GFS have YSU
- Dave and Chunxi looked at the code diffs and identified places that need to be combined (fields needed by WRF-MPAS not in GFS version and vice versa)
- fields with different units, some fields (tracers) in one big array versus split out
- temperature versus potential temperature
- demonstration deadlines coming up soon - when?
- portability aspect of YSU scheme to GFS is not in a critical path
- but portability to CESM early/mid September (when YSU needs to run through CCPP in MPAS)
- will start with the version that in in WRF-MPAS, not with what is in ccpp-physics today
- this version has one horizontal dimension and one vertical dimension
- needs starting and ending for horizontal dimension
- in ccpp_prebuild.py, optional arguments are used to pass the available data (e.g. temperature or potential_temperature) to the scheme
- another option would be to augment the SDF and add information about optional arguments in there (instead of ccpp_prebuild.py)
- what about a host model that doesn't have combined tracer arrays
- in the past, we had discussions that these combined arrays would be constructed based on information in the metadata
- todo: open issues on ccpp-framework
- schemes that take constituent arrays with host models that don't have those arrays
- is this a real problem? none of the models we are working with now/in the near future has this problem
- CCPP constants / constant values for a model run:
- prebuild system could create a parameter file accessible by both the host model and the physics
- especially useful for handling constituent arrays
- in addition, there are some scientific questions (related to cloud ice/water and longwave/shortwave radiation fields)
- schemes that take constituent arrays with host models that don't have those arrays
- do we really want to have two different versions in ccpp-physics? can we agree on a common core and move the rest to model-specific interstitials? this is our first study problem
- Thompson would be easier but that is not in the targeted MPAS suite to port to CCPP first
Standard names discussion (cont'd):
- chemistry folks ok with "interface" and "layer", "level" was termed to be too ambiguous
- "layer" is the default for a 3-d variable, if not need to decorate with "interface", "at_lowest_model_level", ...
- dimensions should follow this terminology: "vertical_layer_dimension", "vertical_interface_dimension"
- cell averages would take another "average" decorator