-
Notifications
You must be signed in to change notification settings - Fork 64
CCPP Framework Meeting Minutes 2019 08 29
Dom Heinzeller edited this page Aug 29, 2019
·
14 revisions
Updates:
- new repository for technical documentation of CCPP to move ccpp-framework/doc out of the repository
- this documentation is not just ccpp-framework related, but includes documentation of FV3, SCM, ...
- if there is documentation purely related to ccpp-framework, this should be kept separate?
- a ccpp-compliant MYJ scheme has been developed by Qingfu Liu from EMC
- this version is as close as possible to the original code and uses CCPP wrappers around it
- the original code contains constructs that CCPP doesn't allow, but just rewriting these parts is not an ideal solution either
- efforts to clean up the code should be coordinated with the WRF community
- would it be better to keep the original code (even if it violates the CCPP requirements) until someone rewrites the scheme completely, instead of taking these intermediate steps?
- general: how to enforce standards such as no stdout/stderr in the absence of a better mechanism for logging
- we need to decide if what we want to implement
- one possibility is marble, which has a error handler
- using marble requires changing all schemes and the ccpp-framework
- then clean up all the schemes to use the new tool
- this needs to be a coordinated effort with WRF and MPAS
- we now have a CCPP prebuild out of source build to accommodate parallel cmake builds
- we now have a metadata2html converter that converts a single file at a time
- create a batch process using ccpp_prebuild.py with an additional flag
Discussion:
- ccpp-framework code (CMakeLists.txt) still contains host-model specific information
- once we have documentation for CCPP and MPAS, do we want to combine this with the existing documentation?
- need to align our standard names and constants with other groups in the UFS and outside, recently got invited to engage with ESPC SCE (what does the SCE acronym stand for?)
- for the December UFS release, do we go with ccpp_prebuild.py or cap_gen.py?
- will cap_gen.py be ready by then?
- lots of functionality is there, but there are bugs and we need time to fix them?
- this would require cleaning up the Fortran code to match with the standard/metadata as enforced by cap_gen
- most likely we will go with ccpp_prebuild.py
Standard names:
- Steve will create a pull request to publish Dave's list of standard names
- this will go to a subdirectory standard_names in the new ccpp-docs repository
- this is in xml format and it comes with a converter to html
- can use ccpp-docs issue page for discussions around standard names
- in the future, these dictionaries could be split into chemistry, physics, ... but need to avoid conflicts
- create a tool to check if standard names used are in the standard_names dictionary, spit out warnings if not