the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
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.
- Preprint
(1120 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 22 Oct 2025)
-
CEC1: 'Comment on egusphere-2025-2548 - No compliance with the policy of the journal', Juan Antonio Añel, 08 Aug 2025
reply
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
reply
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
reply
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
reply
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
reply
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
reply
-
AC2: 'Reply on CEC2', Melanie A. Thurner, 13 Aug 2025
reply
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 12 Aug 2025
reply
-
AC1: 'Reply on CEC1', Melanie A. Thurner, 12 Aug 2025
reply
-
RC1: 'Comment on egusphere-2025-2548', Anonymous Referee #1, 29 Aug 2025
reply
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
Viewed
HTML | XML | Total | BibTeX | EndNote | |
---|---|---|---|---|---|
910 | 30 | 16 | 956 | 8 | 11 |
- HTML: 910
- PDF: 30
- XML: 16
- Total: 956
- BibTeX: 8
- EndNote: 11
Viewed (geographical distribution)
Country | # | Views | % |
---|
Total: | 0 |
HTML: | 0 |
PDF: | 0 |
XML: | 0 |
- 1