the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 05 Aug 2025
Lateral heat fluxes amplify the aggregation error of soil temperature in non-sorted circles
Abstract. Soil properties vary within centimeters, which is not captured by state-of-the-art land-surface models due to their kilometer-scale grid. This mismatch can lead to systematic errors when simulating the exchange of energy, water, and greenhouse gases between the land and atmosphere—collectively referred to as “aggregation error.”
To quantify the potential aggregation error of soil temperature, we developed the two-dimensional pedon-scale geophysical soil model DynSoM-2D, which has a spatial resolution of 10 cm. We applied DynSoM-2D at a permafrost-affected, non-sorted circle site using three different setups: (i) a homogeneous soil profile representing a typical land surface model, compiled by averaging the heterogeneous soil inputs; (ii) the actual heterogeneous soil profile of a typical non-sorted circle; and (iii) the heterogeneous soil profile including lateral heat fluxes.
Our results show that DynSoM simulates warmer soil temperatures when heterogeneous soil properties are considered, with this warming becoming even more pronounced and consistent across the domain when lateral heat fluxes are included. By aggregating grid cells, we traced the aggregation error back to the spatial distribution of organic matter, which nonlinearly alters soil thermal and hydrological properties, leading to the observed differences between simulations. In our case, the heterogeneity-induced warming led to a deepening of the active layer and an extension of the snow-free period, both of which can strongly alter ecosystem dynamics, while having only a minor effect on soil-atmosphere heat exchange on an annual basis.
-
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
(1120 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(1120 KB) - Metadata XML
- BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this preprint
Interactive discussion
Status: closed
-
CEC1: 'Comment on egusphere-2025-2548 - No compliance with the policy of the journal', Juan Antonio Añel, 08 Aug 2025
-
AC1: 'Reply on CEC1', Melanie A. Thurner, 12 Aug 2025
Thank you for your message.
We would like to confirm our understanding of your concerns and apologize for any inconvenience.To make the process hopefully as short as possible, we uploaded our code now to Zenodo, too, and it is now publicly available under https://doi.org/10.5281/zenodo.16798740. We will include the link and reference (Thurner, M. A., Rodriguez-Lloveras, X., & Beer, C. (2025). DynSoM-2D. Zenodo.) in any further versions of our manuscript.
Nevertheless, we want to make clear that it was never our intention to cause any issues. While it is correct that our code has been published with restricted access at the UHH repository to protect our work as long as the manuscript is not under review or published, we provided a confidential link when submitting the paper, which is to our understanding in line with the GMD regulations under specific circumstances. Unfortunately, this link expired while waiting for an editor and we could not change the uploaded link. The expiration of the confidential access is obviously not in line with the GDM regulations and we apologize for this.
Besides of this, we also do not fully understand, why the UHH repository does not meet the GDM requirements for archives, because it has permanent institutional support, which allows to archive code and data for years to decades, prevents the removement of published material, and provides a DOI.
As said, to keep this process short, we now uploaded the code to Zenodo and made it public, but out of personal interest and for further publications: Would had also been in line with GMD regulations, if we would have opened the access to our code at the UHH repository to public?
Kind regards,
Melanie A. Thurner (on behalf of all Co-Authors)
Citation: https://doi.org/10.5194/egusphere-2025-2548-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 12 Aug 2025
Dear authors,
Many thanks for your reply.
First, please, I would thank if you can confirm that the repository that you have shared contains all the input and output data used in your work. I only see a single .csv file in it, which cast some doubts on it. Also, now that we know that your code is in M Language, and that you have used the MatLab interpreter to run it, it would be desirable that you include in potentially reviewed versions of your manuscript de version number of such interpreter, as MatLab does not assure compatibility of code between the different versions that they issue. Also, it would be good if you could clarify if your code can be run with the free M interpreter, GNU Octave, which would make easier the replicability and compatibility of your work.
Regarding your question on the link with the restricted access to the code: this is only an exception that we could make when authors are forbidden to share the code used in their work by a regulation, law or similar, which obviously is not your case. Only under very exceptional circumstances we admit that the code used in a manuscript is not shared before submission, and only after getting clearance for it, after sending us documentary evidence of such legal constraints, we admit that a manuscript undergoes Discussions and peer-review without sharing the code.
Regarding the servers of the University of Hamburg being not suitable to deposit assets linked to published scientific papers, there are several problems. First, despite your words that it exits an institutional commitment to support it, such evidence is not provided in its webpage. Regarding this issue, we usually request at least confirmed funds and commitment to operate a repository for not less than 15-20 years, and a statement in the web page of the repository regarding it. Also, the repository must have a clear policy, published in its webpage. Such policy must contain, at minimum, clear indications about the impossibility by authors to remove any content after it has been deposited, and usually authorizing removal only after a collegiate decision by a board, and because of a limited number of causes, such as legal issues. Unfortunately, and to the best of our knowledge, the service operated by the University of Hamburg lacks the mentioned policy and level of commitment. Therefore, making the information open in the servers of the University of Hamburg would have continued to fail to be in compliance with the Code and Data policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-2548-CEC2 -
AC2: 'Reply on CEC2', Melanie A. Thurner, 13 Aug 2025
Thank you for your message and for answering our questions.
Regarding the input and output: We confirm that the csv file is the only external file that we used to run DynSoM for our manuscript. It contains the site-specific atmospheric forcing. Any other input information can be found in the HSM2d_v01_input_XXX.m files. There are two of them, because we used a homogeneous (_gentsch_hom_) and a heterogeneous (_gentsch_het_) soil input. Any other site-specific information is equal in these input files. If you run the code the output will appear as describes in the readme.txt in the Matlab specific workspace from where you can store any variables. But in addition, we also uploaded now an additional folder (output4manuscript_DynSoM-2D_v01) to Zenodo as Version 2.
We used Matlab version R2023b (23.2) for our code development and will add this information in further versions of our manuscript. Unfortunately, we did not test, if our code can also be run by GNU Octave successfully. We started a test run this morning, but it was very slow and did not end successfully until evening. Since I’m on vacation now, my Co-Author Xavier Rodriguez-Lloveras will finish the test and let you know asap about the outcome.Kind regards,
Melanie A. Thurner (on behalf of all Co-Authors)
Citation: https://doi.org/10.5194/egusphere-2025-2548-AC2 -
CC1: 'Reply on AC2', Xavier rodriguez-Lloveras, 01 Sep 2025
Dear Editor,
Regarding the use of the free M interpreter, GNU Octave, we would like to clarify that the model is programmed and optimised to work in MatLab.
The use of Octave is not recommended, as the nested structure nature of our code makes it extremely slow. In addition the model calls timing functions specific to MatLab , which are not recognised by Octave and prompt an error during the time-step-to-daily conversion section of the code. However the main processes of the code can be runt, the time-step-wise results exported, and they match the ones produced with MatLab.
As the code scripts can be downloaded, the code can be edited to adapt to Octave specific timing utilities, and the model should be able to run completely.
As expressed, we don't recommend running the code in Octave as the running time is about 20 times longer than in MatLab.
With kind regards,
Xavier Rodriguez-Lloveras
Citation: https://doi.org/10.5194/egusphere-2025-2548-CC1
-
CC1: 'Reply on AC2', Xavier rodriguez-Lloveras, 01 Sep 2025
-
AC2: 'Reply on CEC2', Melanie A. Thurner, 13 Aug 2025
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 12 Aug 2025
-
AC1: 'Reply on CEC1', Melanie A. Thurner, 12 Aug 2025
-
RC1: 'Comment on egusphere-2025-2548', Anonymous Referee #1, 29 Aug 2025
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-2548/egusphere-2025-2548-RC1-supplement.pdf
- AC3: 'Reply on RC1', Melanie A. Thurner, 11 Nov 2025
-
RC2: 'Comment on egusphere-2025-2548', Anonymous Referee #2, 11 Oct 2025
The manuscript presents an attempt to quantify the significance of the treatment of small-scale variations in soil properties on the simulated soil and surface temperatures, as well as the surface heat fluxes. The effects of heterogeneity and their impact on larger-scale averages are undoubtedly intriguing topics that warrant the attention of the modeling community. However, I think the manuscript would benefit from some revisions of the description of the model and analysis, and expanding of analysis to include the effects of interannual variability.
To start, I would suggest changing the title of the manuscript. First, for readers not intimately familiar with the permafrost features and process, it is not at all obvious what “non-sorted circles” in the title refers to. As a very minimum, the title should make it clear that the study is specific to the permafrost processes. Second, the focus of the study is on the differences in results of several modeling approaches, but to the casual reader the term “aggregation error” implies comparison with observations (or the perfect representation of the processes), which is not the focus of the manuscript. I recommend avoiding this term, at least in the title.
I think another problem is that the description of the model misses an essential part: the method used to calculate surface turbulent fluxes. Clearly, on such a small horizontal scale of ~10 cm that the described model uses, the Monin-Obukhov Similarity Theory (MOST) approach commonly employed in large-scale mosaic schemes would not work because a number of assumptions important for the MOST applicability are violated. Therefore, it is essential to describe what alternative approach was used to calculate surface fluxes, especially given that a significant portion of the manuscript is devoted to the analysis of differences in turbulent fluxes and energy balance. Without that, it is very hard to judge the validity of the results.
The description also seems to contradict itself, saying in section 2.1.1 that “a prescribed skin temperature (see following section) serves as the upper boundary condition”, while equation (3) implies that the surface skin temperature is calculated given the atmospheric meteorological forcing and prognostic equations of water and energy balance in the soil. I think providing more details about the calculation of surface fluxes and energy balance would help to resolve this confusion.
In the section describing the results of the simulations, the authors chose to limit the analysis of the results to just one year, but the motivation is not entirely clear to me: the text in lines 191-192 says “to preserve the current atmospheric forcing signal, which is strongly superimposed when another averaging method is used.” I am not sure about the meaning of this phrase; especially since it somewhat contradicts the one-week smoothing applied to the results to “avoid overly fuzzy near-surface” values. I think analyzing and presenting the statistics across all available years of forcing is essential to take into account the interannual variability and to have confidence in the robustness of the results.
This does not, of course, preclude using the results from one year (or one season) as an example illustrating physical processes, if necessary.
In the description of the energy-related fluxes and balances, the authors frequently use the confusing phrase “kW/m^2 per day”: the fluxes are typically measured in W/m^2, and it is absolutely not clear what “per day” refers to. Similarly confusing is the phrase “°C per day” in the description of the range of temperatures.
Assuming that my understanding of the units used in the analysis is correct, some of the energy balance numbers seem to be unreasonably large. For example, on lines 221-223, the manuscript says “the total simulated annual heat budget … (M0: 13.7kW/m2, M1: 14.1kW/m2, M2: 13.5kW/m2)”. Of course, the total long-term average energy balance at the surface of the well-spun-up land model should be close to zero, so it is not clear what these numbers represent.
I can only assume that these results represent the annual average sum of sensible and latent heat fluxes (which should compensate radiative fluxes), but even then the numbers seem excessively high. For comparison, the solar radiation incident on the area perpendicular to the sun rays at the top of the Earth atmosphere is ~1360 W/m2. It is not clear how it is possible that the annual heat balance at the site (~69N latitude) can be so large, given attenuating factors due to site latitude, annual averaging, and absorption/reflection/scattering by the atmosphere and clouds. Unless this is a typo, an explanation must be provided. Likewise, the intra-model differences in heat fluxes are on the order of hundreds of W/m2: that of course is not impossible on the short time scale, but would strongly depend on the way the turbulent fluxes are calculated, and needs to be discussed.
In figure A1, soil water content is measured in kg/kg; this is kilogram of water per kilogram of what dry soil or wet soil? Or per dry soil+ice? Why the commonly accepted definition of volumetric water content is not used?
Technical comments:
Line 38, and elsewhere replace “snow height” with “snow depth”
L 171: Provide coordinates for Cherskii site
L 178: Typo: “growthto” should be “growth to”
L 203: Replace “horizon-wise averaged” with “horizontally averaged”
Caption of figure 2, and elsewhere: does T_surf refer to the temperature of the soil surface, or the surface interacting with the atmosphere (i.e. surface of the snowpack if present and soil surface T otherwise)?
Caption of figure 2: “T_soil, all depths” — does it mean averaged over entire soil column?
Citation: https://doi.org/10.5194/egusphere-2025-2548-RC2 - AC4: 'Reply on RC2', Melanie A. Thurner, 11 Nov 2025
Interactive discussion
Status: closed
-
CEC1: 'Comment on egusphere-2025-2548 - No compliance with the policy of the journal', Juan Antonio Añel, 08 Aug 2025
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.htmlFirst, the repository cited in your "Code and Data Availability" statement has the access restricted. I am sorry to have to be so outspoken, but this is something completely unacceptable, forbidden by our policy, and your manuscript should have never been accepted for Discussions given such lack of compliance with our policy, which you should have read before submitting your manuscript and clearly states that all the code and data necessary to replicate a manuscript must be published openly and freely to anyone before submission.
Second, you have stored your code and data in servers of the University of Hamburg. Again, our policy clearly lists the acceptable repositories to store assets when submitting a manuscript to our journal. The University of Hamburg servers do not comply with the minimum requirements for repositories for scientific publication and are not included in our list of acceptable repositories. Therefore, you must publish all the code (models, scripts, etc.) and data (input and output data, configuration files, etc.) used for your work, in one of the acceptable repositories.
At this point, the situation with your manuscript is highly irregular, and as I said, should not be in Discussions or under review in our journal. Therefore, we are granting you a short time to solve this situation. You have to reply to this comment in a prompt manner with the information requested. The reply must include the links and permanent identifiers (e.g. DOI) for the new repositories. Also, any future version of your manuscript must include the modified section with the new information.
I must note that if you do not fix this problem, we cannot continue with the peer-review process or accept your manuscript for publication in our journal.
Juan A. Añel
Geosci. Model Dev. Executive EditorCitation: https://doi.org/10.5194/egusphere-2025-2548-CEC1 -
AC1: 'Reply on CEC1', Melanie A. Thurner, 12 Aug 2025
Thank you for your message.
We would like to confirm our understanding of your concerns and apologize for any inconvenience.To make the process hopefully as short as possible, we uploaded our code now to Zenodo, too, and it is now publicly available under https://doi.org/10.5281/zenodo.16798740. We will include the link and reference (Thurner, M. A., Rodriguez-Lloveras, X., & Beer, C. (2025). DynSoM-2D. Zenodo.) in any further versions of our manuscript.
Nevertheless, we want to make clear that it was never our intention to cause any issues. While it is correct that our code has been published with restricted access at the UHH repository to protect our work as long as the manuscript is not under review or published, we provided a confidential link when submitting the paper, which is to our understanding in line with the GMD regulations under specific circumstances. Unfortunately, this link expired while waiting for an editor and we could not change the uploaded link. The expiration of the confidential access is obviously not in line with the GDM regulations and we apologize for this.
Besides of this, we also do not fully understand, why the UHH repository does not meet the GDM requirements for archives, because it has permanent institutional support, which allows to archive code and data for years to decades, prevents the removement of published material, and provides a DOI.
As said, to keep this process short, we now uploaded the code to Zenodo and made it public, but out of personal interest and for further publications: Would had also been in line with GMD regulations, if we would have opened the access to our code at the UHH repository to public?
Kind regards,
Melanie A. Thurner (on behalf of all Co-Authors)
Citation: https://doi.org/10.5194/egusphere-2025-2548-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 12 Aug 2025
Dear authors,
Many thanks for your reply.
First, please, I would thank if you can confirm that the repository that you have shared contains all the input and output data used in your work. I only see a single .csv file in it, which cast some doubts on it. Also, now that we know that your code is in M Language, and that you have used the MatLab interpreter to run it, it would be desirable that you include in potentially reviewed versions of your manuscript de version number of such interpreter, as MatLab does not assure compatibility of code between the different versions that they issue. Also, it would be good if you could clarify if your code can be run with the free M interpreter, GNU Octave, which would make easier the replicability and compatibility of your work.
Regarding your question on the link with the restricted access to the code: this is only an exception that we could make when authors are forbidden to share the code used in their work by a regulation, law or similar, which obviously is not your case. Only under very exceptional circumstances we admit that the code used in a manuscript is not shared before submission, and only after getting clearance for it, after sending us documentary evidence of such legal constraints, we admit that a manuscript undergoes Discussions and peer-review without sharing the code.
Regarding the servers of the University of Hamburg being not suitable to deposit assets linked to published scientific papers, there are several problems. First, despite your words that it exits an institutional commitment to support it, such evidence is not provided in its webpage. Regarding this issue, we usually request at least confirmed funds and commitment to operate a repository for not less than 15-20 years, and a statement in the web page of the repository regarding it. Also, the repository must have a clear policy, published in its webpage. Such policy must contain, at minimum, clear indications about the impossibility by authors to remove any content after it has been deposited, and usually authorizing removal only after a collegiate decision by a board, and because of a limited number of causes, such as legal issues. Unfortunately, and to the best of our knowledge, the service operated by the University of Hamburg lacks the mentioned policy and level of commitment. Therefore, making the information open in the servers of the University of Hamburg would have continued to fail to be in compliance with the Code and Data policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-2548-CEC2 -
AC2: 'Reply on CEC2', Melanie A. Thurner, 13 Aug 2025
Thank you for your message and for answering our questions.
Regarding the input and output: We confirm that the csv file is the only external file that we used to run DynSoM for our manuscript. It contains the site-specific atmospheric forcing. Any other input information can be found in the HSM2d_v01_input_XXX.m files. There are two of them, because we used a homogeneous (_gentsch_hom_) and a heterogeneous (_gentsch_het_) soil input. Any other site-specific information is equal in these input files. If you run the code the output will appear as describes in the readme.txt in the Matlab specific workspace from where you can store any variables. But in addition, we also uploaded now an additional folder (output4manuscript_DynSoM-2D_v01) to Zenodo as Version 2.
We used Matlab version R2023b (23.2) for our code development and will add this information in further versions of our manuscript. Unfortunately, we did not test, if our code can also be run by GNU Octave successfully. We started a test run this morning, but it was very slow and did not end successfully until evening. Since I’m on vacation now, my Co-Author Xavier Rodriguez-Lloveras will finish the test and let you know asap about the outcome.Kind regards,
Melanie A. Thurner (on behalf of all Co-Authors)
Citation: https://doi.org/10.5194/egusphere-2025-2548-AC2 -
CC1: 'Reply on AC2', Xavier rodriguez-Lloveras, 01 Sep 2025
Dear Editor,
Regarding the use of the free M interpreter, GNU Octave, we would like to clarify that the model is programmed and optimised to work in MatLab.
The use of Octave is not recommended, as the nested structure nature of our code makes it extremely slow. In addition the model calls timing functions specific to MatLab , which are not recognised by Octave and prompt an error during the time-step-to-daily conversion section of the code. However the main processes of the code can be runt, the time-step-wise results exported, and they match the ones produced with MatLab.
As the code scripts can be downloaded, the code can be edited to adapt to Octave specific timing utilities, and the model should be able to run completely.
As expressed, we don't recommend running the code in Octave as the running time is about 20 times longer than in MatLab.
With kind regards,
Xavier Rodriguez-Lloveras
Citation: https://doi.org/10.5194/egusphere-2025-2548-CC1
-
CC1: 'Reply on AC2', Xavier rodriguez-Lloveras, 01 Sep 2025
-
AC2: 'Reply on CEC2', Melanie A. Thurner, 13 Aug 2025
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 12 Aug 2025
-
AC1: 'Reply on CEC1', Melanie A. Thurner, 12 Aug 2025
-
RC1: 'Comment on egusphere-2025-2548', Anonymous Referee #1, 29 Aug 2025
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-2548/egusphere-2025-2548-RC1-supplement.pdf
- AC3: 'Reply on RC1', Melanie A. Thurner, 11 Nov 2025
-
RC2: 'Comment on egusphere-2025-2548', Anonymous Referee #2, 11 Oct 2025
The manuscript presents an attempt to quantify the significance of the treatment of small-scale variations in soil properties on the simulated soil and surface temperatures, as well as the surface heat fluxes. The effects of heterogeneity and their impact on larger-scale averages are undoubtedly intriguing topics that warrant the attention of the modeling community. However, I think the manuscript would benefit from some revisions of the description of the model and analysis, and expanding of analysis to include the effects of interannual variability.
To start, I would suggest changing the title of the manuscript. First, for readers not intimately familiar with the permafrost features and process, it is not at all obvious what “non-sorted circles” in the title refers to. As a very minimum, the title should make it clear that the study is specific to the permafrost processes. Second, the focus of the study is on the differences in results of several modeling approaches, but to the casual reader the term “aggregation error” implies comparison with observations (or the perfect representation of the processes), which is not the focus of the manuscript. I recommend avoiding this term, at least in the title.
I think another problem is that the description of the model misses an essential part: the method used to calculate surface turbulent fluxes. Clearly, on such a small horizontal scale of ~10 cm that the described model uses, the Monin-Obukhov Similarity Theory (MOST) approach commonly employed in large-scale mosaic schemes would not work because a number of assumptions important for the MOST applicability are violated. Therefore, it is essential to describe what alternative approach was used to calculate surface fluxes, especially given that a significant portion of the manuscript is devoted to the analysis of differences in turbulent fluxes and energy balance. Without that, it is very hard to judge the validity of the results.
The description also seems to contradict itself, saying in section 2.1.1 that “a prescribed skin temperature (see following section) serves as the upper boundary condition”, while equation (3) implies that the surface skin temperature is calculated given the atmospheric meteorological forcing and prognostic equations of water and energy balance in the soil. I think providing more details about the calculation of surface fluxes and energy balance would help to resolve this confusion.
In the section describing the results of the simulations, the authors chose to limit the analysis of the results to just one year, but the motivation is not entirely clear to me: the text in lines 191-192 says “to preserve the current atmospheric forcing signal, which is strongly superimposed when another averaging method is used.” I am not sure about the meaning of this phrase; especially since it somewhat contradicts the one-week smoothing applied to the results to “avoid overly fuzzy near-surface” values. I think analyzing and presenting the statistics across all available years of forcing is essential to take into account the interannual variability and to have confidence in the robustness of the results.
This does not, of course, preclude using the results from one year (or one season) as an example illustrating physical processes, if necessary.
In the description of the energy-related fluxes and balances, the authors frequently use the confusing phrase “kW/m^2 per day”: the fluxes are typically measured in W/m^2, and it is absolutely not clear what “per day” refers to. Similarly confusing is the phrase “°C per day” in the description of the range of temperatures.
Assuming that my understanding of the units used in the analysis is correct, some of the energy balance numbers seem to be unreasonably large. For example, on lines 221-223, the manuscript says “the total simulated annual heat budget … (M0: 13.7kW/m2, M1: 14.1kW/m2, M2: 13.5kW/m2)”. Of course, the total long-term average energy balance at the surface of the well-spun-up land model should be close to zero, so it is not clear what these numbers represent.
I can only assume that these results represent the annual average sum of sensible and latent heat fluxes (which should compensate radiative fluxes), but even then the numbers seem excessively high. For comparison, the solar radiation incident on the area perpendicular to the sun rays at the top of the Earth atmosphere is ~1360 W/m2. It is not clear how it is possible that the annual heat balance at the site (~69N latitude) can be so large, given attenuating factors due to site latitude, annual averaging, and absorption/reflection/scattering by the atmosphere and clouds. Unless this is a typo, an explanation must be provided. Likewise, the intra-model differences in heat fluxes are on the order of hundreds of W/m2: that of course is not impossible on the short time scale, but would strongly depend on the way the turbulent fluxes are calculated, and needs to be discussed.
In figure A1, soil water content is measured in kg/kg; this is kilogram of water per kilogram of what dry soil or wet soil? Or per dry soil+ice? Why the commonly accepted definition of volumetric water content is not used?
Technical comments:
Line 38, and elsewhere replace “snow height” with “snow depth”
L 171: Provide coordinates for Cherskii site
L 178: Typo: “growthto” should be “growth to”
L 203: Replace “horizon-wise averaged” with “horizontally averaged”
Caption of figure 2, and elsewhere: does T_surf refer to the temperature of the soil surface, or the surface interacting with the atmosphere (i.e. surface of the snowpack if present and soil surface T otherwise)?
Caption of figure 2: “T_soil, all depths” — does it mean averaged over entire soil column?
Citation: https://doi.org/10.5194/egusphere-2025-2548-RC2 - AC4: 'Reply on RC2', Melanie A. Thurner, 11 Nov 2025
Peer review completion
Journal article(s) based on this preprint
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 12 | 4 | 0 | 16 | 2 | 1 |
- HTML: 12
- PDF: 4
- XML: 0
- Total: 16
- BibTeX: 2
- EndNote: 1
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Melanie A. Thurner
Xavier Rodriguez-Lloveras
Christian Beer
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(1120 KB) - Metadata XML
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.html
First, the repository cited in your "Code and Data Availability" statement has the access restricted. I am sorry to have to be so outspoken, but this is something completely unacceptable, forbidden by our policy, and your manuscript should have never been accepted for Discussions given such lack of compliance with our policy, which you should have read before submitting your manuscript and clearly states that all the code and data necessary to replicate a manuscript must be published openly and freely to anyone before submission.
Second, you have stored your code and data in servers of the University of Hamburg. Again, our policy clearly lists the acceptable repositories to store assets when submitting a manuscript to our journal. The University of Hamburg servers do not comply with the minimum requirements for repositories for scientific publication and are not included in our list of acceptable repositories. Therefore, you must publish all the code (models, scripts, etc.) and data (input and output data, configuration files, etc.) used for your work, in one of the acceptable repositories.
At this point, the situation with your manuscript is highly irregular, and as I said, should not be in Discussions or under review in our journal. Therefore, we are granting you a short time to solve this situation. You have to reply to this comment in a prompt manner with the information requested. The reply must include the links and permanent identifiers (e.g. DOI) for the new repositories. Also, any future version of your manuscript must include the modified section with the new information.
I must note that if you do not fix this problem, we cannot continue with the peer-review process or accept your manuscript for publication in our journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor