The CryoGrid community model (version 1.0) – a multi-physics toolbox for climate-driven simulations in the terrestrial cryosphere
Abstract. The CryoGrid community model is a flexible toolbox for simulating the ground thermal regime and the ice/water balance for permafrost and glaciers, extending a well-established suite of permafrost models (CryoGrid 1, 2 and 3). The CryoGrid community model can accommodate a wide variety of application scenarios, which is achieved by fully modular structures through object-oriented programming. Different model components, characterized by their process representations and parametrizations, are realized as classes (i.e. objects) in CryoGrid. Standardized communication protocols between these classes ensure that they can be stacked vertically. For example, the CryoGrid community model features several classes with different complexity for the seasonal snow cover which can be flexibly combined with a range of classes representing subsurface materials, each with their own set of process representations (e.g. soil with and without water balance, glacier ice).
We present the CryoGrid architecture as well as the model physics and defining equations for the different model classes, focusing on one-dimensional model configurations which can also interact with external heat and water reservoirs. We illustrate the wide variety of simulation capabilities for a site on Svalbard, with point-scale permafrost simulations using e.g. different soil freezing characteristics, drainage regimes and snow representations, as well as simulations for glacier mass balance and a shallow water body. The CryoGrid community model is not intended as a static model framework, but aims to provide developers with a flexible platform for efficient model development. In this study, we document both basic and advanced model functionalities to provide a baseline for the future development of novel cryosphere models.
Sebastian Westermann et al.
Status: final response (author comments only)
- RC1: 'Comment on gmd-2022-127', Anonymous Referee #1, 20 Jul 2022
- RC2: 'Comment on gmd-2022-127', Anonymous Referee #2, 08 Feb 2023
- EC1: 'Comment on gmd-2022-127', Christopher Horvat, 08 Feb 2023
Sebastian Westermann et al.
Sebastian Westermann et al.
Viewed (geographical distribution)
The CryoGrid community model (version 1.0) - a multi-physics toolbox for climate-driven simulations in the terrestrial cryosphere
The paper describes the CryoGrid model, which was initially developed to study the permafrost thermal process. The current model has multiple versions, and the capabilities of the model were substantially expanded, covering a broad spectrum of physical processes. The authors used Matlab's object-oriented programming to achieve modeling modularity, allowing swapping different methods and physics into the GryoGrid model. Increasing physical complexity of the model comes at the expense of computing time. It would be nice to have a graph showing how increasing model complexity affects model performance. The model is written in Matlab, which likely reduces the adoption of the model since not every organization or individual has access to a Matlab license. In addition, Matlab is an interpretive language and requires a certain style of code development which could lead to potential slowdowns in the execution time. I suggest including in the discussion why Matlab language was chosen and its downsides compared to the compiler languages like C++ and Fortran. Otherwise, this work is an important step that contributes to the development of the community types model. It would be nice to have a discussion about similar community-type models like CLM and others (similarities and differences). What are the benefits of loose versus tight coupling between different physical processes? Any thoughts on how the modular approach can be standardized and implemented across multiple platforms? How can mathematical programming like OpenFoam be helpful in moving toward usability and modularity?
Reading this technical paper without seeing examples of the code makes the overall understanding hard. I suggest adding the snippets of the code or pseudo code to illustrate the model design and structure (e.g. Line 201, explanation of the CHILD using code).
L 345. For more clarity, it would be nice to represent the grid schematically with the boundary condition included for one or multiple stratigraphy classes.
Are stratigraphies and physical processes the same things?
L394. Soil types. Are they mixed within the bulk soil layer or discrete and vary per depth?
2.2.9 I guess enabling different physical classes e.g. permafrost and glaciers, would significantly slow down the simulation. Can you provide any charts showing the execution time when adding more coupled different physical processes? Moving to 3D would substantially reduce the compute time. It would be nice to provide some estimates on that as well.
L699. Which version of the CryoGrid is used there? Similarly, include a version of the model was used to produce figures 5 and 6.
Figure 7. It talks about the ice impedance factor but there is no formula showing it.
Section 3.2. I suggest adding a few figures.
Figures 11 and 12 replace captions.
Figure 19 It looks like red and dashes red increase snow density too slowly, making soils much warmer, suggesting that these two formulations are not even appropriate.
L1108. Data assimilation or calibration?