Our answers to the reviewers comments are written below, between the original reviewer comments. Our answers are in italic and manuscript parts in bold italic

---

1.

First off all, I want to congratulate the authors on this great piece of work. The manuscript provides really valuable and timely insights, especially now when the scientific community is paying more attention to software quality and making sure geoscientific models can be reliably reproduced. Combining the hands-on experience of modelers within the Global Carbon Project with the perspective of software engineers creates a solid and much-needed approach. Their thorough review of current practices and suggestions for best practices (e.g. covering testing, documentation, continuous integration, portability, and reproducibility) are a big step forward for the carbon modeling community and, more generally, for climate modeling as a whole.

The effort they put into gathering real-world experiences, pinpointing issues, and sharing concrete examples—like the case of LPJ-GUESS—really shows strong teamwork and a real commitment to making scientific software more strong and sustainable. That said, I have some questions and thoughts that popped up while reading this article, and I think they might help deepen the discussion. 

We thank the reviewer for these encouraging remarks. We are indeed hopeful that our paper will be helpful for the community.

2.

For example, the article emphasizes that automated testing setups and strategies like CI/CD aren’t widely used, even though they’re really important. It also points out that many models run on high-performance computing (HPC) system which can be expensive and take weeks to run. Given this, what ideas do you have for expanding testing and continuous integration methods to HPC environments and intercomparison projects like CMIP6/CMIP7, where resources are tight and running models costs a lot?

Thank you for this valid remark. We added some information on this issue, highlighting how to efficiently use testing.

In the testing section:

Notably, a test coverage summary shows which processes are not being executed by tests at all and may hint at how the testing setup can be extended to also cover these parts of the model.

In the CI section:

Regarding testing of such complex software pieces like geo-scientific models, the test design plays a key role. We recommend small-scale runs that can already identify issues arising in new implementations without having to run entire global simulations. Reducing the amount of grid cells, or patches, or for instance PFTs can already greatly reduce the computational load while still allowing to test a lot of functionality. Within the community, a common approach is also running global tests for short timescales of a few simulation years, but trying to test all processes of the models. As noted before, test coverage tools may help to pinpoint sections of the code that are not well tested. For larger testing, hybrid parallelization (via the combination of MPI and OpenMP) can reduce parallelization costs, while dynamic load balancing can improve the efficiency of processor work loads. Large-scale tests could run on timed bases, like once per week, or simply be triggered on commit or manually.

3. 

The article also mentions that reproducibility is often challenged by the diversity in environments, things like different compilers, HPC systems, and local setups. Even following FAIR data principles and sharing in open repositories doesn’t always ensure workflows can be repeated easily. Have you thought about ways to tackle these reproducibility barriers across different institutions? Do you see moving towards more standardized containers and environment managers (like Conda, Docker, Singularity) as a practical step to narrowing this gap?

This is a very important point. We clarified that these tools are discussed in the manuscript by adding a sentence to the introductory paragraph of section 6 Reproducibility, usability, and portability of scientific workflows and results:

We will discuss how to make workflows reproducible with workflow automation tools like Snakemake and targets, ensuring correct environment setups with package managers like Conda or Renv, and facilitating portability across systems by using container frameworks like Docker or Singularity. Furthermore, we will introduce PEcAn, a tool that can also help make model usage more accessible and repeatable in general.

4. 

Also, the coexistence of various programming languages such as Fortran, C, and C++, makes it necessary to keep code readable, portable, and maintainable. With the ongoing shift towards newer paradigms, like migrating from Fortran to C++/Python and the increasing use of GPUs and hybrid architectures, what practices would you recommend to keep code sustainable over the next 10–20 years?

Thank you for this valid remark. We added a short subsection on this topic:

6.2.3 Facilitating portability to new infrastructures and paradigms

The software world is evolving rapidly, with new programming languages, paradigms, environments, and infrastructures emerging continuously. Though at a slower pace, geo-scientific models are also required to be ported to new realms. The practices discussed previously can help address this. In particular, comprehensive test coverage (Sec. 3.1) enables safe refactoring and facilitates porting code to newer versions. Environment managers (Sec. 6.2.1) support updating or replacing dependencies, while containerization (Sec. 6.2.2) helps use software in different infrastructures. In addition, numerous AI-based tools are now available to assist with porting code across languages and platforms. Here, a robust testing framework is also crucial for ensuring correctness throughout such transitions.

5.

I also believe making public code repositories accessible is essential, as platforms like Zenodo (mentioned in the article for sharing model versions) are really effective for preserving and sharing software. Do you think these repositories should become a standard part of our community’s toolkit?

Yes. We added this point in the text:

We propose that using such open repositories should be the standard for all modeling communities. Notably, public version control offers many benefits for the community, as new implementations become readily available and the community can provide feedback and directly contribute to development, testing and assessment of new features. Repositories like Zenodo, on the other hand, are beneficial, because they store data and code versions in a permanent fashion (whereas a group could switch version control systems and historic versions could be lost).

6.

Improve the maintainability and readability of Fortran code in these models is a very hard challenge. Since 13 out of 20 GCP land surface models (LSMs) are written in Fortran, have you considered integrating a specific analyser tool into the development and CI pipelines?  Do you think using FortranAnalyser could become a standard for the community, especially since it not only helps find potential errors but also encourages standard coding styles, modularity, and best practices in long-term projects like the GCP LSMs? This open-source tool stands out because it can analyse any version of Fortran, unlike others like F-Lint or fortran-src. This flexibility is especially useful since different Fortran standards coexist in scientific work, and it can even be customized to add specific metrics useful to the development team. If yes, do you see any technical or cultural challenges in adopting it widely?

Yes, this is an important point. We clarified how FortranAnalyser and similar tools can be used in the CI pipeline by restructuring and rewording our section. We refrained from mentioning clear version numbers as the FortranAnalyser website does not specify that it can handle all Fortran versions, and fortran-src also can analyse multiple versions.

The text that was reworded and enhanced is this:

The most commonly used tools for the LSM-languages are clang-tidy for C++, and F-Lint for Fortran. The latter, however, is not freely available. Free alternatives for static Fortran code analysis are, e.g., fortran-src (Contrastin et al., 2025) and FortranAnalyser (García-Rodríguez et al., 2024). Such static code analyses and code formatting should be enforced by integrating the tools into CI pipelines and local development, such as pre-commit hooks, which automatically run them before commits.

We would like to thank the reviewer for their thorough assessment of our manuscript, which pointed out inconsistencies and flaws. We addressed these aspects and believe this significantly improved our manuscript.

We would like to respond to the four major criticisms, namely 1) the use of LLMs for text editing, 2) the usage of one specific model for the example, 3) the criticism of the capability of scientists in terms of programming, and 4) the situation of funding.

The comments by the reviewer were quite critical but raised important points, on most of which the authors agree. We are confident that addressing them has improved the paper by quite a lot. In the following we will address the comments in more detail:

First, we have to refute the claim about the author’s contributions and AI use. Indeed, all authors contributed intellectually to different parts of the manuscript. The fact that still inconsistencies and flaws were found shows the importance of an external and unbiased peer review. We did use ChatGPT for language editing, but we have hundreds of emails, 20+ survey responses, and intermediate paper versions from well over one year to challenge that this paper or even parts of it were AI-generated. In fact, this paper started as a short paper by the first author on coding tips for modeling communities. An initial submission was challenged by the editors of GMD because it was not detailed enough, and it was suggested to include insights from other model communities. This led to a constantly growing manuscript with the insights of now 32 people, and offers a scope much larger than that of recently published papers that focus on single aspects (like Docker, version control, code review, FAIR, etc., see References 1–5 below).

Second, the reviewer wonders why the model LPJ-GUESS was stated as “most successful in the field”. While we neither believe nor say this, we did realize now that we used it for most examples, simply because the first author is most familiar with it. We now removed the mention of this particular model in almost all cases because while the example figures or code snippets are based on this model, they are relevant for all models. In addition to our existing disclaimer about examples not being endorsements/criticism in the introduction, we added more claims like this, and more clearly indicate that for the pipeline example (previously “showcase”) we selected one model for pragmatic reasons and reduced the mentioning of which model we used for this to a minimum. We also worked in more references to the appendix (examples of all the model communities) to make sure benefits of numerous models are highlighted.

Third, the reviewer raises concerns about our criticism of the work/skill of the community. We realize now that the tone we picked was not ideal and more negative than it was intended to be (notably, considering that the author team represents numerous models, we were criticizing our own work). We have thoroughly revised the manuscript to adopt a neutral tone.

Fourth, the reviewer disagrees with our claims about the lack of time and money in this field, because they have enough time and money. For us, this highlights the relevance of including authors working with multiple models. The situation described by the reviewer does not align with the experience raised by multiple co-authors of this paper as well as that of surveys which we cite, therefore we prefer to keep this notion in the paper but extended the claims to show that experiences may differ.

---

Since the formatting options of the reply text box are very limited, and since there were a large number of detailed comments, leading also to complex changes in the manuscript, we decided to provide the answer to the reviewer's comments in an attached PDF file. We believe that this makes it easier to assess the original comments and the answers and corresponding changes.

On behalf of all co-authors,

Konstantin Gregor