the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 18 Oct 2022
The Common Community Physics Package (CCPP) Framework v6
Dominikus Heinzeller
Ligia R. Bernardet
Grant J. Firl
Man Zhang
Xia Sun
Michael B. Ek
Abstract. The Common Community Physics Package (CCPP) is a collection of atmospheric physical parameterizations for use in Earth system models and a framework that couples the physics to a host model’s dynamical core. A primary goal for this effort is to facilitate research and development of physical parameterizations and experimentation with physics-dynamics coupling methods, while simultaneously offering capabilities for use in numerical weather prediction (NWP) operations. The CCPP Framework supports configurations ranging from process studies to operational NWP as it enables host models to assemble the parameterizations in flexible suites. Framework capabilities include variability of scheme call order, ability to group parameterizations for calls in different parts of the host model allowing intervening computation or coupling to additional components, options to call some parameterizations more often than others, and automatic variable transformations.
The CCPP Framework was developed by the Developmental Testbed Center and is distributed with a single-column model that can be used to test innovations and to conduct hierarchical studies in which physics and dynamics are decoupled. It is also an integral part of the Unified Forecast System, a community-based, coupled, comprehensive Earth modeling system designed to support research and be the source system for the National Oceanic and Atmospheric Administration (NOAA) operational NWP applications. Finally, the CCPP Framework is under various stages of adoption by a number of other models in the wider community.
-
Notice on discussion status
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
-
Preprint
(3062 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(3062 KB) - BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this preprint
Dominikus Heinzeller et al.
Interactive discussion
Status: closed
-
CC1: 'Comment on egusphere-2022-855', Ligia Bernardet, 26 Oct 2022
Mike Ek's affiliation should be ammended to reflect a second affiliation with NCAR Research Applications Laboratory.
Citation: https://doi.org/10.5194/egusphere-2022-855-CC1 - RC1: 'Comment on egusphere-2022-855', Anonymous Referee #1, 15 Dec 2022
-
RC2: 'Comment on egusphere-2022-855', Anonymous Referee #2, 06 Jan 2023
The Common Community Physics Package (CCPP) Framework v6Â
The paper describes interesting concept on generalization of atmospheric physics to be accessible from various numerical models. It tries to introduce some flexibility to the physics-dynamics interface to the Common Community Physics Package (CCPP) through imposing standardized rules and uniform structure. Paper gives an adequate overview about this activity with two examples of its potential use. Â The text is well written and relatively easy to be followed. The manuscript is certainly logically structured.ÂÂ
General comment:
Rather than providing detailed scientific and/or technical discussions justifying the driving motivation for this effort the manuscript feels like code documentation or summary of rules to be followed when intending to use or develop the CCPP. The text is on the other hand not sufficiently detailed to serve as a crash course, neither to be regarded as a manual. As a reviewer I struggle to grab the purpose of this paper: It feels like a message to the community perhaps an advertisement of the completed work but certainly not a scientific paper. With this regard it is difficult to argue about anything presented. Reader can simply learn about it but no justification of the decision along the line is given. We all know the devil is in details, but the paper is far from such complexity and to discuss the adopted paths. Like that the paper can serve as a decent overview. If this is the intent and the text suites the editorial concept of the Journal the presented paper can be easily accepted for publication. Still, it may be worth authors consider giving bit more arguments supporting the presented choices. The questions bellow grouped into three areas reflect my personal take for the sort of information missing in the manuscript.
Â
Specific comments:
On a more scientific aspects one would like to learn about the level of flexibility this presented interface can offer. For example, can the proposed interface accommodate both sequential and parallel attitude to various physics processes? Can one easily change order of schemes within the package (like for example to swap convection and vertical diffusion or to call saturation adjustment multiple times after several processes)? Does the interface support inter-timestep history to average physical processes over certain time range? And if so, would it follow the Lagrangian path to maintain the best spatial and temporal consistency? Or does it support some flexibility for partial call of physics during split dynamics or predictor-corrector type of model. Can the package (or part of it) be used in an implicit way? Would the interface easily digest when some processes are replaced by super-parameterizations with its own specific computational stencils? How the conservation (and of what quantities) is being ensured within this flexible framework? I understand those are questions beyond the scope addressed by this paper. Still, a reader might be given some overview about the assumed scientific flexibility for the presented interface.
When regarding the CCPP from more technical side, the presented text also leaves some unanswered questions. The assumed organization of fields requires the first index (ensuring the most optimal memory access for the inner loops) to be the number of 1D columns in a chunk. The recent evidence favours to prioritize data storage along vertical levels (i.e. to have vertical levels as the first index) for GPU processing in order to be most benefiting there. Naturally, one may assume the choice adopted for CCPP is not the most optimal with this regard. Or does the CCPP possess any tool to easily swap array ordering to suite this eventual requirement? Listing 1 (page 7) implies all the data are copied both ways between the host model space and the CCPP. Although this may allow some flexibility and potential to fully control precision during the CCPP computation this step would certainly significantly affect the code efficiency. Have authors considered to use some better alternatives (like pointers) to avoid this massive and repetitive data move? It should be fair to present some estimates about pros and cons of this controversial step to convince reader about the adopted strategy.
Finally, the presented very ambitions and huge work implies increased level of discipline for the code maintenance and development. (The CCPP code may be evaluated for use in a model not available to the evaluation team.) From this reason it is perhaps worth to mention any specific policy mechanism ensuring the rules are being maintained and followed by all contributors. Is there some reviewing committee with the right to accept the new code? And what is the policy to adopt the presented rules in the case their modification is required in a future (to accommodate a new scheme)?
Citation: https://doi.org/10.5194/egusphere-2022-855-RC2 -
AC1: 'Comment on egusphere-2022-855', Dom Heinzeller, 03 Feb 2023
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2022/egusphere-2022-855/egusphere-2022-855-AC1-supplement.pdf
Interactive discussion
Status: closed
-
CC1: 'Comment on egusphere-2022-855', Ligia Bernardet, 26 Oct 2022
Mike Ek's affiliation should be ammended to reflect a second affiliation with NCAR Research Applications Laboratory.
Citation: https://doi.org/10.5194/egusphere-2022-855-CC1 - RC1: 'Comment on egusphere-2022-855', Anonymous Referee #1, 15 Dec 2022
-
RC2: 'Comment on egusphere-2022-855', Anonymous Referee #2, 06 Jan 2023
The Common Community Physics Package (CCPP) Framework v6Â
The paper describes interesting concept on generalization of atmospheric physics to be accessible from various numerical models. It tries to introduce some flexibility to the physics-dynamics interface to the Common Community Physics Package (CCPP) through imposing standardized rules and uniform structure. Paper gives an adequate overview about this activity with two examples of its potential use. Â The text is well written and relatively easy to be followed. The manuscript is certainly logically structured.ÂÂ
General comment:
Rather than providing detailed scientific and/or technical discussions justifying the driving motivation for this effort the manuscript feels like code documentation or summary of rules to be followed when intending to use or develop the CCPP. The text is on the other hand not sufficiently detailed to serve as a crash course, neither to be regarded as a manual. As a reviewer I struggle to grab the purpose of this paper: It feels like a message to the community perhaps an advertisement of the completed work but certainly not a scientific paper. With this regard it is difficult to argue about anything presented. Reader can simply learn about it but no justification of the decision along the line is given. We all know the devil is in details, but the paper is far from such complexity and to discuss the adopted paths. Like that the paper can serve as a decent overview. If this is the intent and the text suites the editorial concept of the Journal the presented paper can be easily accepted for publication. Still, it may be worth authors consider giving bit more arguments supporting the presented choices. The questions bellow grouped into three areas reflect my personal take for the sort of information missing in the manuscript.
Â
Specific comments:
On a more scientific aspects one would like to learn about the level of flexibility this presented interface can offer. For example, can the proposed interface accommodate both sequential and parallel attitude to various physics processes? Can one easily change order of schemes within the package (like for example to swap convection and vertical diffusion or to call saturation adjustment multiple times after several processes)? Does the interface support inter-timestep history to average physical processes over certain time range? And if so, would it follow the Lagrangian path to maintain the best spatial and temporal consistency? Or does it support some flexibility for partial call of physics during split dynamics or predictor-corrector type of model. Can the package (or part of it) be used in an implicit way? Would the interface easily digest when some processes are replaced by super-parameterizations with its own specific computational stencils? How the conservation (and of what quantities) is being ensured within this flexible framework? I understand those are questions beyond the scope addressed by this paper. Still, a reader might be given some overview about the assumed scientific flexibility for the presented interface.
When regarding the CCPP from more technical side, the presented text also leaves some unanswered questions. The assumed organization of fields requires the first index (ensuring the most optimal memory access for the inner loops) to be the number of 1D columns in a chunk. The recent evidence favours to prioritize data storage along vertical levels (i.e. to have vertical levels as the first index) for GPU processing in order to be most benefiting there. Naturally, one may assume the choice adopted for CCPP is not the most optimal with this regard. Or does the CCPP possess any tool to easily swap array ordering to suite this eventual requirement? Listing 1 (page 7) implies all the data are copied both ways between the host model space and the CCPP. Although this may allow some flexibility and potential to fully control precision during the CCPP computation this step would certainly significantly affect the code efficiency. Have authors considered to use some better alternatives (like pointers) to avoid this massive and repetitive data move? It should be fair to present some estimates about pros and cons of this controversial step to convince reader about the adopted strategy.
Finally, the presented very ambitions and huge work implies increased level of discipline for the code maintenance and development. (The CCPP code may be evaluated for use in a model not available to the evaluation team.) From this reason it is perhaps worth to mention any specific policy mechanism ensuring the rules are being maintained and followed by all contributors. Is there some reviewing committee with the right to accept the new code? And what is the policy to adopt the presented rules in the case their modification is required in a future (to accommodate a new scheme)?
Citation: https://doi.org/10.5194/egusphere-2022-855-RC2 -
AC1: 'Comment on egusphere-2022-855', Dom Heinzeller, 03 Feb 2023
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2022/egusphere-2022-855/egusphere-2022-855-AC1-supplement.pdf
Peer review completion
Journal article(s) based on this preprint
Dominikus Heinzeller et al.
Model code and software
Common Community Physics Package (CCPP) Single Column Model v6.0.0 (with Physics and Framework) Grant Firl, Ligia Bernardet, Man Zhang, Mike Kavulich, Dustin Swales, Jimy Dudhia, Mike Ek https://doi.org/10.5281/zenodo.6896438
Dominikus Heinzeller et al.
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 506 | 136 | 15 | 657 | 9 | 6 |
- HTML: 506
- PDF: 136
- XML: 15
- Total: 657
- BibTeX: 9
- EndNote: 6
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(3062 KB) - Metadata XML