the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 26 May 2026
TopoToolbox 3, a laboratory for quantitative geomorphology
Abstract. TopoToolbox has been widely used to analyze and model landscapes across geomorphology and other geospatial disciplines for the past 15 years. Its documentation and accessible interfaces have made it a valuable resource for teaching and learning quantitative geomorphology while its customizability and efficiency have allowed researchers to use it as a platform for experimentation and implementation of their own analyses and models. Its third version, TopoToolbox 3, builds on these developments by improving access to the software, integrating with a larger ecosystem of geomorphology software, and establishing sustainable research software engineering practices. TopoToolbox, previously available only on the MATLAB platform, is now also available to users of Python, and an R interface is under development. The redesigned architecture of TopoToolbox 3 is based on a shared library of core computational routines that makes these and other integrations possible while maintaining the MATLAB interface for existing users of the software. We illustrate the power of this design with examples of how users can integrate TopoToolbox into their workflows. First, we compare the implementation of a basic application, $\chi$ maps, in MATLAB and Python. Second, we use the GraphFlood hydraulic model, now available in TopoToolbox, to showcase the potential of integrating simulation tools and analyzing their output in one computational environment. Third, we demonstrate a two-way coupling between TopoToolbox and the Python-based Landlab landscape evolution modeling framework. Finally, we show how property-based testing can successfully identify bugs in the absence of known solutions to test cases. We conclude by discussing how improved quality assurance and community-driven development practices ensure that TopoToolbox continues to serve the evolving needs of the geomorphology community.
Competing interests: Some authors are members of the editorial board of journal Earth Surface Dynamics.
Publisher's note: Copernicus Publications remains neutral with regard to jurisdictional claims made in the text, published maps, institutional affiliations, or any other geographical representation in this paper. While Copernicus Publications makes every effort to include appropriate place names, the final responsibility lies with the authors. Views expressed in the text are those of the authors and do not necessarily reflect the views of the publisher.- Preprint
(1460 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
-
CC1: 'Comment on egusphere-2026-2478', Benoît Bovy, 01 Jun 2026
-
AC1: 'Reply on CC1', William Kearney, 08 Jun 2026
> This manuscript presents TopoToolbox 3, a re-designed set of software
> components that provide tools for both topographic analysis and
> modelling.> The manuscript illustrates well how the development of TopoToolbox 3
> follows the principles of Findability, Accessibility,
> Interoperability, and Reusability (FAIR) for research software. For
> example, section 2.3.4 describes how it integrates with Landlab,
> another software widely used for landscape evolution modelling.> I'd like to emphasize that developing research software according to
> the FAIR principles is a significant undertaking (API and architecture
> design, documentation, testing and continuous-integration, packaging,
> reviews, etc.) that has the potential of greatly benefiting an entire
> community. I believe that TopoToolbox 3 will be no exception for the
> Geomorphology community. Such effort merits recognition and credit,
> and I sincerely hope that TopoToolbox 3 maintainers and contributors
> will get all the credit they deserve!Thanks for the very kind words.
> I'd also like to note that besides TopoToolbox 3 (and Landlab),
> there exists other stacks of software that share similar broad — more
> or less ambitious — objectives and features, that have been developed
> using the same FAIR principles and that together have been benefiting
> the same community. This includes, among others, Fastscape
> (https://github.com/fastscape-lem) and LSDTopoTools
> (https://github.com/LSDtopotools). The manuscript could certainly be
> more effective at mentioning such relevant projects, perhaps with some
> brief sentences on how they compare with TopoToolbox 3 and/or how they
> might be integrated with each other, conceding that an exhaustive
> review or thorough comparison is well outside of the scope
> here. Sadly, though, this appears to have been completely overlooked
> in the current version of the manuscript (e.g., no citation found for
> any of the aforementioned projects). Improving this aspect in the
> manuscript would be useful, much appreciated and — mostly — fair.This point is well taken. The manuscript does not thoroughly review
the many tools that do similar tasks to TopoToolbox. The focus is
currently on the integrations that we have accomplished (i.e. with
Landlab), and the question of how to integrate TopoToolbox with these
other tools is largely left up to the reader's imagination. We will
address this in a revised version of the manuscript by including more
discussion of the state of landscape analysis software in 2026.Citation: https://doi.org/10.5194/egusphere-2026-2478-AC1
-
AC1: 'Reply on CC1', William Kearney, 08 Jun 2026
-
RC1: 'Comment on egusphere-2026-2478', Yizhou Wang, 20 Jun 2026
I am glad to see this work. That’s surely valuable. TopoToolbox has already been widely used in a wide variety of fields including but not limited to tectonic geomorphology, geology, hydrology, glaciology and even ecology. The previous versions are based on Matlab platform, which may lack the extension with GIS software and landscape evolution modelling packages. This new version developed by Kearney et al. is available for Python, an open-source platform that is supported by e.g. QGIS, landlab … . There is no doubt that the development is at the state of art and will meet the evolving needs of the geoscience community.
I only propose two minor suggestions. 1) What is and how to calculate chi, because this software is widely used and not every reader is familiar with this metric. 2) A shematic showing the function and work flow of TopoToolbox, may be I missed this part.
This manuscript is well written and no grammar errors.
Citation: https://doi.org/10.5194/egusphere-2026-2478-RC1 -
AC2: 'Reply on RC1', William Kearney, 14 Jul 2026
Thank you for your comment and your helpful suggestions.
I only propose two minor suggestions. 1) What is and how to calculate chi, because this software is widely used and not every reader is familiar with this metric.
We will add a brief description of chi and explain how it is computed both mathematically and in TopoToolbox at the beginning of Section 2.3.1
2) A shematic showing the function and work flow of TopoToolbox, may be I missed this part.
There is not necessarily a single workflow for TopoToolbox, and there are far too many functions to illustrate clearly in a single figure. However, we can relatively easily add a diagram that illustrates the chi maps workflow in section 2.3.1 and how the steps in that workflow are translated to the code examples currently shown in Figure 2.
Citation: https://doi.org/10.5194/egusphere-2026-2478-AC2
-
AC2: 'Reply on RC1', William Kearney, 14 Jul 2026
-
RC2: 'Comment on egusphere-2026-2478', Anonymous Referee #2, 10 Jul 2026
Over the last 15 years, TopoToolbox has become a valuable and widely used open-source package for topographic analysis. This paper presents a major new release, which adds a Python interface and includes a major restructuring of the software to allow it to support multiple languages. To my mind, this is a very nice contribution. The new capabilities substantially broaden the scope of TopoToolbox and its interoperability with other packages and across languages. The development of a Python interface is especially significant because it allows users to do combined analyses with TopoToolbox and an expanding collection of other Python-language scientific packages, without having to switch between languages or needing a Matlab license. At the same time, retaining the original Matlab interface provides backward compatibility and serves the large Matlab user base in geoscience. Coding the core routines in a shared C library seems like an effective strategy for enabling cross-language capability.
The examples presented in the manuscript nicely illustrate its capabilities. I especially appreciate the thoughtful and comprehensive approach to software testing and quality control. The manuscript is well written, and the figures clearly designed. Pointers to supporting code allow readers to try out the examples for themselves. The authors might also consider saying more about what community involvement looks like in practice, how the software is managed and governed, and how contribution is encouraged and supported (beyond the technical practices of continuous integration and pull requests). I realize, however, that this may go beyond the scope of this paper.
One potential area for improvement would be to explain how code reviews are handled. The manuscript notes that community contributions are encouraged, and that they are done via pull requests. But apart from a passing mention around line 422, nothing further is said about code reviews: who does them, what criteria are used, etc. Adding a few sentences about this would help give readers a sense of what might be involved in making contributions.
Overall, in my view this manuscript is a great example of how geoscience research software should be presented in journal articles. I recommend publication after minor revisions.
Comments keyed to text:37-49 I appreciate this list of examples of use of TT combined with other software.
115-119 use of contiguous arrays rather than objects is an interesting strategy, and one that is similar to the approach used by the Basic Model Interface, where data handling is kept simple in order to accommodate languages like C and Fortran.
149-155 I'm not totally clear on the platform compatibility issue here. Any compiled library will need to be compiled specifically for a given hardware, so it is only portable in the sense that compilation is possible across different architectures. Is there something special about data-tiling that restricts it to only certain platforms and not others? And why would this not also be an issue for the hardware acceleration frameworks, mentioned? For example, if a particular acceleration requires an NVIDIA GPU, how is that portable? Obviously, this isn't a big deal here, since the point of the discussion is just to note possible future solutions to this problem, but I'm guessing that a little editing in this paragraph could help make the issue clearer for readers.
158-164 Is the automated test suite run on multiple platforms and OS versions?
170 Is snapshot testing the same as what is sometimes called regression testing?
198 metamorphic testing is new to me, and the example helps make it understandable. The authors might consider adding a second example.
214 I tested the chi-map Jupyter notebook, and was able to run it without much difficulty. The only obstacles were (1) I had to install GDAL separately using conda (after trying a pip install and then getting problems related to a missing config file) before successfully pip-installing topotoolbox, and (2) I didn't see an obvious way to download the notebook from the gallery, so I used view source, which works for the notebook but then the auxiliary data file is missing. Consider providing a link to the full set of notebooks and data files for the paper in the Figure 2 caption.
216 missing 'from'
219 missing comma
226 Why the reprojection? Do some algorithms require projected horizontal ground units?
254 This bug is a nice example of the value of metamorphic testing - bravo to the authors for their openness in showing it.
270 This is great example of interoperability!
315 a little more explanation would be helpful here. Is the idea that one package projects the data while the other uses geographic coordinates? Or they both project but with different projections?
322-324 Although I think I understand the gist here, it's not totally clear to me what 'complementary' means in this context, or why the lack of overlap implies signals beyond 1D. Consider re-wording.
362 Not clear what 'original Landlab example' refers to here.
404 Great point - needs to happen!
419 The sentence's subject should really be the developers, not the software itself.
427-9 This sentence confused me at first because it suggests that the hardware and/or OS differences are to blame. But then the next paragraph suggests that it's not this at all but rather seems to be different behavior of rasterio and the MappingToolbox.
449 This reads as if apologizing for a limitation, but I would argue that this is absolutely appropriate. Understanding when/how/where models do or do not approximate the real world is the domain of science, not software development. The key point is that the software enables the science. Further, creating and exploring new models (whether models of processes or of terrain or whatever) is itself a key part of the scientific method. So I don't see the 'unvalidated' nature of software like this as a problem, as long as the scientific status of various algorithms and models (demonstrably accurate vs. provisional best-guess vs. rough approximation with big uncertainties vs. untested speculation, etc.) is clear in the literature and documentation.
Citation: https://doi.org/10.5194/egusphere-2026-2478-RC2 -
AC3: 'Reply on RC2', William Kearney, 23 Jul 2026
Thank you very much for the comments. I've tried to clear up some sources of confusion below and indicate how we can address them in a revised manuscript.
Over the last 15 years, TopoToolbox has become a valuable and widely used open-source package for topographic analysis. This paper presents a major new release, which adds a Python interface and includes a major restructuring of the software to allow it to support multiple languages. To my mind, this is a very nice contribution. The new capabilities substantially broaden the scope of TopoToolbox and its interoperability with other packages and across languages. The development of a Python interface is especially significant because it allows users to do combined analyses with TopoToolbox and an expanding collection of other Python-language scientific packages, without having to switch between languages or needing a Matlab license. At the same time, retaining the original Matlab interface provides backward compatibility and serves the large Matlab user base in geoscience. Coding the core routines in a shared C library seems like an effective strategy for enabling cross-language capability.
The examples presented in the manuscript nicely illustrate its capabilities. I especially appreciate the thoughtful and comprehensive approach to software testing and quality control. The manuscript is well written, and the figures clearly designed. Pointers to supporting code allow readers to try out the examples for themselves. The authors might also consider saying more about what community involvement looks like in practice, how the software is managed and governed, and how contribution is encouraged and supported (beyond the technical practices of continuous integration and pull requests). I realize, however, that this may go beyond the scope of this paper.
One potential area for improvement would be to explain how code reviews are handled. The manuscript notes that community contributions are encouraged, and that they are done via pull requests. But apart from a passing mention around line 422, nothing further is said about code reviews: who does them, what criteria are used, etc. Adding a few sentences about this would help give readers a sense of what might be involved in making contributions.
This is a good suggestion and one that I think we can easily add.
Overall, in my view this manuscript is a great example of how geoscience research software should be presented in journal articles. I recommend publication after minor revisions.
Comments keyed to text:
37-49 I appreciate this list of examples of use of TT combined with other software.
115-119 use of contiguous arrays rather than objects is an interesting strategy, and one that is similar to the approach used by the Basic Model Interface, where data handling is kept simple in order to accommodate languages like C and Fortran.
149-155 I'm not totally clear on the platform compatibility issue here. Any compiled library will need to be compiled specifically for a given hardware, so it is only portable in the sense that compilation is possible across different architectures. Is there something special about data-tiling that restricts it to only certain platforms and not others? And why would this not also be an issue for the hardware acceleration frameworks, mentioned? For example, if a particular acceleration requires an NVIDIA GPU, how is that portable? Obviously, this isn't a big deal here, since the point of the discussion is just to note possible future solutions to this problem, but I'm guessing that a little editing in this paragraph could help make the issue clearer for readers.
I think a problem here and elsewhere in the manuscript is that we implicitly use an expansive definition of "platform" that includes not only the hardware and operating system but also other software and tangible aspects of users' workflows. This is admittedly confusing, and we will clarify what we mean by "platform" or find a better way to phrase this.
In this sense of "platform," the generic approach of data tiling can be used from many platforms. However, the implementations of tiling algorithms are not portable. Barnes describes this problem: "The design ... is general enough to be implemented with either threads or processes using any of a number of technologies including OpenMP, MPI, Apache Spark ..., or MapReduce .... Here, I use MPI" (2017, p. 203). A user who wants to incorporate Barnes' algorithm into a Spark workflow would need to implement the algorithm again for Spark, but either implementation could be made to run on a Linux/x86-64 machine or a macOS/ARM machine.
libtopotoolbox's goal is that the single C implementation can be used from multiple languages with data obtained from a variety of sources. It does need to be compiled for different hardware architectures and operating systems. For code that adheres to the ISO C standards with no external dependencies, this is primarily an exercise in orchestrating different compilers and distributing the compiled artifacts rather than a real obstacle to portability. The downside is that libtopotoolbox can only interact with the lowest common denominator of its supported platforms, which is the contiguous array of data in memory.
The parallelization and hardware acceleration approaches mentioned in this section are explicitly non-portable alternatives to libtopotoolbox that could enable big data processing within the multilingual setup of TopoToolbox 3. This can be made clearer in the manuscript.
158-164 Is the automated test suite run on multiple platforms and OS versions?
It is. We will add more details.
170 Is snapshot testing the same as what is sometimes called regression testing?
Snapshot testing is a kind of regression testing. The main feature of snapshot testing is that it doesn't evaluate whether the results are correct at all, only that they haven't changed from the existing output. Other forms of regression tests might use known analytical solutions, for example. We can add some text that makes this distinction more clear.
198 metamorphic testing is new to me, and the example helps make it understandable. The authors might consider adding a second example.
An earlier draft did not have the separate metamorphic testing example, so the flow directions bug was described here, but we can add another brief example to the text here.
214 I tested the chi-map Jupyter notebook, and was able to run it without much difficulty. The only obstacles were (1) I had to install GDAL separately using conda (after trying a pip install and then getting problems related to a missing config file) before successfully pip-installing topotoolbox, and (2) I didn't see an obvious way to download the notebook from the gallery, so I used view source, which works for the notebook but then the auxiliary data file is missing. Consider providing a link to the full set of notebooks and data files for the paper in the Figure 2 caption.
If you feel comfortable opening an issue on pytopotoolbox about the installation problems, we can look into them more. Ideally GDAL would get installed as part of our dependency on rasterio, but this doesn't happen in all cases. We may need some additional documentation for when installation goes wrong.
The complete examples can also be downloaded from the gallery repository (https://github.com/TopoToolbox/gallery). We will add a link there in the manuscript. We can also add a link to the auxiliary data file in the chi maps example itself.
216 missing 'from'
219 missing commaCorrected
226 Why the reprojection? Do some algorithms require projected horizontal ground units?
In principle they do not, but TopoToolbox has historically assumed that data come in projected form, and some functions will not behave as expected when data are not projected. We therefore generally recommend projecting data before using it in either our Python or MATLAB implementations. We are working on using data in geographic coordinate systems where possible and making it more apparent to users which functionality will and will not work in geographic coordinate systems, but that work is ongoing.
We can add some text to the manuscript that makes this more clear.
254 This bug is a nice example of the value of metamorphic testing - bravo to the authors for their openness in showing it.
270 This is great example of interoperability!
315 a little more explanation would be helpful here. Is the idea that one package projects the data while the other uses geographic coordinates? Or they both project but with different projections?
There is more detail in the Discussion around Line 435, and we can move some of those details here. The two packages project the data into the same coordinate system, but the projection algorithms are different. It may be possible to configure the two projection functions of the two different packages so they produce numerically identical outputs, but those configuration options are not currently exposed in either pytopotoolbox or the MATLAB topotoolbox3.
322-324 Although I think I understand the gist here, it's not totally clear to me what 'complementary' means in this context, or why the lack of overlap implies signals beyond 1D. Consider re-wording.
We will try to clear this up. It is intended to mean that the width and shear stress provide more information than either alone and that 2D hydrodynamics capture signals beyond along-profile variations, which are analyzed in 1D methods like TopoToolbox's Stream objects.
362 Not clear what 'original Landlab example' refers to here.
This refers to the Wickert and Gasparini notebook in the Landlab gallery. We will add a citation here to clarify.
404 Great point - needs to happen!
419 The sentence's subject should really be the developers, not the software itself.
Corrected.
427-9 This sentence confused me at first because it suggests that the hardware and/or OS differences are to blame. But then the next paragraph suggests that it's not this at all but rather seems to be different behavior of rasterio and the MappingToolbox.
This, again, is our expansive definition of platform in which rasterio and the MappingToolbox are part of the "platform". We will make this more clear.
449 This reads as if apologizing for a limitation, but I would argue that this is absolutely appropriate. Understanding when/how/where models do or do not approximate the real world is the domain of science, not software development. The key point is that the software enables the science. Further, creating and exploring new models (whether models of processes or of terrain or whatever) is itself a key part of the scientific method. So I don't see the 'unvalidated' nature of software like this as a problem, as long as the scientific status of various algorithms and models (demonstrably accurate vs. provisional best-guess vs. rough approximation with big uncertainties vs. untested speculation, etc.) is clear in the literature and documentation.
I think we are totally in agreement here, and we can try to make this paragraph sound a bit more positive. We mainly want to emphasize that our testing of TopoToolbox 3 does not replace scientific validation and model comparison. Conversely, some contributors have struggled to design test cases for TopoToolbox because they have assumed that software tests need to be scientifically relevant validation tests, but we primarily want verification tests in our test suite.
Citation: https://doi.org/10.5194/egusphere-2026-2478-AC3
-
AC3: 'Reply on RC2', William Kearney, 23 Jul 2026
-
RC3: 'Comment on egusphere-2026-2478', Anonymous Referee #3, 23 Jul 2026
Summary:
This manuscript introduces readers to TopoToolbox3, which is a significant advance over the previous version of the open-source software, in that the fundamental architecture has changed, allowing a new Python-based interface and easier integration with other software. The manuscript is exceptionally well-written with only a few typos. Despite the complexity of the topic, particularly for those not familiar with the software, the platforms, or with coding in general, it is still accessible and clear. I have a few suggestions for inclusions and clarifications, but overall, this is an important manuscript and should be published with minor revisions. I offer a few general comments for the authors to consider below, followed by a few line-by-line and figure comments.
General comments:
- I find manuscripts like this necessarily awkward – a new tool or database clearly requires a formal, peer-reviewed introduction to the community, along with an establishment of the framework and testing protocols and provision a few useful examples, as is done nicely here. But the authors aren’t presenting and interpretating new results, so the traditional background-methods-results-discussion format doesn’t work. To that end, the authors might consider reorganizing the methods and results sections and removing these headings. The format could be 2. Architecture and design decisions, 3. Testing and quality assurance, 4. Practical evaluation of TopoToolbox3 (including both methods and results for the X maps, GraphFlood, metamorphic testing, and integration with Landlab), then 5. Discussion.
- More on organization, I found that the X maps and metamorphic testing where more clearly assessments, whereas the integration with Landlab and GraphFlood were more about showcasing new capabilities. I would reorder the presentation to follow this progression.
- More on the awkwardness of trying to cover all angles in a paper like this – I think that the manuscript serves existing TopoToolbox users well. However, I suspect that many potential new users will start with reading this manuscript but will find it overwhelming and not end up finding their way to the how-to-guides and tutorials, or older publications. I would suggest adding a subheading to the introduction on scope, perhaps starting around and including the material at line 67, adding text to that section on what is NOT in scope, including that this manuscript is not intended as a how-to-guide or starting point, but rather an update on an existing tool. The authors can then include appropriate links for where people SHOULD start. Yes, this appears later in the manuscript, but highlighting it in the introduction will, I think, be useful.
- One pretty significant omission in the manuscript is a consideration of AI. It will be used, that’s just the new reality – by new users trying to figure out how to get started, or for coding or trouble shooting. I would like to see the author’s perspective on how to realistically and productively use AI in conjunction with TopoToolbox. It would also be helpful to have the authors including tips for working with AI and test which AI platforms (Claude, CoPilot, ChatGPT) work best.
- One aspect I think many users are looking for is better integration between TopoToolbox and ArcGIS or QGIS. This gets teased in lines 35-36, and briefly addressed in line 62, but it does not appear later in the manuscript. The authors make it clear that a QGIS integration is in the works, and obviously this manuscript doesn’t need to wait for that to get finished. What I would suggest is that the authors add a future work section to the end of the discussion that summarizes ongoing work, including GIS integrations, so that readers who might have missed these brief mentions early in the manuscript won’t be left hanging. This is a good opportunity in general for the authors to summarize what other work is planned or already underway, and what is yet to be started but would be good someday. Get people excited about TopoToolbox4, or making their own contributions down the line.
- Finally, that community contributions piece felt quite unclear to me. This is addressed in lines 416-423, but there it feels like the process is vague and no responsibility is assigned. Which tests serves as a shared repository? The tests are automated? Who integrates them (continuously)? How do contributors make changes? How do they test their changes? How exactly to the tests coevolve with the code? What happens when it is unclear how code should be tested or what properties need to be preserved? Who does the careful code review? A clearer workflow would be helpful and might be more encouraging to community members who are keen to contribute. Perhaps an example could be given.
Specific comments:
- Figure 1: This figure could be cleaned up a little and the color coding could be made more intuitive. For example, perhaps blue for the libtopotoolbox box, and green for pybind11 and MEX, indicating visually that they communicate between the library and MATLAB/Python (by blending blue and green, get it?). I’d love to see different colors for TopoToolbox3 (and a darker shade for the MATLAB related packages) compared to the Python side of the figure (and associated packages). Would it be possible to add workflow arrows or more annotations directly on the figure?
- Line 153: I caught this example here, but there are likely others. Not all users will automatically know which functions or packages go with MATLAB vs. Python. Is the Parallel Computing Toolbox a MATLAB thing? If so, add “in MATLAB” after “Toolbox.” I also found line 145 a difficult to read for similar reasons.
- Line 216: There’s something not quite right here. Add “from” between “computed” and “the”?
- Figure 5: The mismatch between Python- and MATLAB-based X results goes away completely if the raster is reprojected outside of TopoToolbox, right? I didn’t get that from the figure and figure capture alone. This information could be added to the caption, or a second figure with the X analysis run on the externally reprojected raster could be added. I guess I just was looking for more advice on how to deal with problems and the authors do seems to have advice here, but it gets lost if one isn’t paying enough attention. So, add it to the figure.
- Line 337: I think there should be a comma between “ties” and “the”
- Figure 7: The authors could add counterclockwise and clockwise (right?) arrows to c and d respectively to illustrate more clearly how tie-breaking is done differently.
- Line 470: Add a comma after “C”.
Citation: https://doi.org/10.5194/egusphere-2026-2478-RC3 -
RC4: 'Comment on egusphere-2026-2478', Anonymous Referee #4, 24 Jul 2026
In this manuscript Kearney et al. present a new version of TopoToolbox, TopoToolbox 3. TopoToolbox has been widely used in quantitative geomorphology for over a decade, and this latest version extends the toolbox into Python, alongside the original MATLAB, and the development of other programming languages. The manuscript provides an overview of the architecture of the software, followed by some examples comparing outputs from Matlab and Python, and some examples of the enhanced interoperability with other Python software such as Landlab. I somewhat agree with Reviewer 3 that the manuscript is awkward, in that it does not present any new findings or interpretations, but requires peer review. I wonder whether the manuscript may have been better suited to a short communication, as the previous version was, or to a more software specific journal (GMD). Having said that, at this stage I don’t think it would be appropriate to either significantly modify, or move the manuscript elsewhere. Overall, the manuscript is well written and organised and could be published with some minor revisions.
I just have one general comment and a couple of line comments.
General Comment
I appreciate that Python has the advantage of not requiring the MATLAB licence, as described on lines 30-35, and has the advantage of being able to be integrated more easily with other programming languages compared to MATLAB. However, is there a sustainability issue with the Python version, in that it is dependent on a number of libraries for which versions of the library may update or become deprecated over time. Do the authors foresee this being an issue down the line, in a way that it is less of an issue for MATLAB users? A small comment on this trade-off between Python and MATLAB might make a welcome addition to the discussion.
Line Comments:
Line 216-217: Sentence missing a word - Chi is computed using/ with?
Line 237: I didn’t realise you could use plotdz to plot a chi plot, but I realise now it is very simple using the ‘distance’, chi, parameter name/value pair for plotdz (at least in matlab). Maybe this was already said in a blog post, but this could be added to the github documentation of plotdz to make it obvious it can be used for chi plots? Very very minor detail and not necessary to this manuscript, but could be useful!
Figure 4. There is a straight river at around 4280 East and 2720 west that appears to have different chi values. I think this may be an optical illusion to do with the different coloured basemaps – the matlab has a darker hillshade? Could the basemaps be made identical? Or is this difficult/not possible to achieve due to discrepancies in plotting between python and matlab?
Section 3.4 and Figure 8 – The chi plots don’t collapse perfectly in chi space, which they should do on a perfectly simulated landscape. Do you know whether this is caused by the pixel size, numerical diffusion, or the inclusion of a hillslope term?
Citation: https://doi.org/10.5194/egusphere-2026-2478-RC4
Model code and software
topotoolbox3 William Kearney, Wolfgang Schwanghart, Dirk Scherler, Richard Ott, Gina Arnau https://doi.org/10.5281/zenodo.20322894
libtopotoolbox William Kearney, Boris Gailleton, Gina Arnau, Theophil Bringezu, Florian Katerndahl, Kilian Lenz, Wolfgang Schwanghart https://doi.org/10.5281/zenodo.20269315
pytopotoolbox William Kearney, Boris Gailleton, Theophil Bringezu, Gina Arnau, Luca Malatesta, François Faure, Xiaochuan Ye https://doi.org/10.5281/zenodo.20209621
Interactive computing environment
TopoToolbox Gallery William Kearney, Wolfgang Schwanghart, Boris Gailleton https://doi.org/10.5281/zenodo.20270725
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 283 | 99 | 17 | 399 | 8 | 7 |
- HTML: 283
- PDF: 99
- XML: 17
- Total: 399
- BibTeX: 8
- EndNote: 7
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
This manuscript presents TopoToolbox 3, a re-designed set of software components that provide tools for both topographic analysis and modelling.
The manuscript illustrates well how the development of TopoToolbox 3 follows the principles of Findability, Accessibility, Interoperability, and Reusability (FAIR) for research software. For example, section 2.3.4 describes how it integrates with Landlab, another software widely used for landscape evolution modelling.
I'd like to emphasize that developing research software according to the FAIR principles is a significant undertaking (API and architecture design, documentation, testing and continuous-integration, packaging, reviews, etc.) that has the potential of greatly benefiting an entire community. I believe that TopoToolbox 3 will be no exception for the Geomorphology community. Such effort merits recognition and credit, and I sincerely hope that TopoToolbox 3 maintainers and contributors will get all the credit they deserve!
I'd also like to note that besides TopoToolbox 3 (and Landlab), there exists other stacks of software that share similar broad — more or less ambitious — objectives and features, that have been developed using the same FAIR principles and that together have been benefiting the same community. This includes, among others, Fastscape (https://github.com/fastscape-lem) and LSDTopoTools (https://github.com/LSDtopotools). The manuscript could certainly be more effective at mentioning such relevant projects, perhaps with some brief sentences on how they compare with TopoToolbox 3 and/or how they might be integrated with each other, conceding that an exhaustive review or thorough comparison is well outside of the scope here. Sadly, though, this appears to have been completely overlooked in the current version of the manuscript (e.g., no citation found for any of the aforementioned projects). Improving this aspect in the manuscript would be useful, much appreciated and — mostly — fair.
(Full disclosure: I’m maintainer of the Fastscape software stack and this comment represents my own view)