[REVIEW]: The Kestrel software for simulations of morphodynamic Earth-surface flows

[editorialbot]

Submitting author: @jakelangham (Jake Langham)
Repository: https://github.com/jakelangham/kestrel/
Branch with paper.md (empty if default branch):
Version: v1.0.0
Editor: @crvernon
Reviewers: @mdpiper, @jatkinson1000
Archive: 10.5281/zenodo.10477693

Status

Status badge code:

HTML: <a href="https://joss.theoj.org/papers/36cb6c0373fcbe7d38598fcfe878ab58"><img src="https://joss.theoj.org/papers/36cb6c0373fcbe7d38598fcfe878ab58/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/36cb6c0373fcbe7d38598fcfe878ab58/status.svg)](https://joss.theoj.org/papers/36cb6c0373fcbe7d38598fcfe878ab58)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@mdpiper & @jatkinson1000, your review will be checklist based. Each of you will have a separate checklist that you should update when carrying out your review.
First of all you need to run this command in a separate comment to create the checklist:

@editorialbot generate my checklist

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @crvernon know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Checklists

📝 Checklist for @jatkinson1000

📝 Checklist for @mdpiper

[editorialbot]

Hello humans, I'm @editorialbot, a robot that can help you with some common editorial tasks.

For a list of things I can do to help you, just type:

@editorialbot commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@editorialbot generate pdf

[editorialbot]

Software report:

github.com/AlDanial/cloc v 1.88  T=0.07 s (939.0 files/s, 346252.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Fortran 90                      31           3102           2525          12230
m4                               9            362             16           1875
reStructuredText                12            726            105           1321
C++                              2            180            157            835
Julia                            2             95             94            501
TeX                              1             16              0            233
Markdown                         2             38              0            229
C/C++ Header                     2             52            345            144
make                             3              9              7             43
Bourne Shell                     1             10              6             41
Python                           1             14             13             29
DOS Batch                        1              8              1             26
YAML                             2              6             24             25
-------------------------------------------------------------------------------
SUM:                            69           4618           3293          17532
-------------------------------------------------------------------------------


gitinspector failed to run statistical information for the repository

[editorialbot]

Wordcount for paper.md is 1569

[editorialbot]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.5194/gmd-2023-80 is OK
- 10.5194/egusphere-2023-1301 is OK
- 10.1016/j.jvolgeores.2004.06.014 is OK
- 10.1007/978-3-030-34356-9_10 is OK
- 10.3389/feart.2020.00275 is OK
- 10.1098/rspa.2013.0819 is OK
- 10.1098/rspa.2013.0820 is OK
- 10.1029/2019JF005204 is OK
- 10.1007/s10346-021-01733-2 is OK
- 10.1016/j.coldregions.2010.04.005 is OK
- 10.1016/j.ijdrr.2022.103338 is OK
- 10.1002/2013RG000447 is OK
- 10.1061/(ASCE)0733-9429(2004)130:7(689) is OK
- 10.1017/jfm.2021.235 is OK
- 10.1017/s0022112098002250 is OK
- 10.1007/b138657 is OK
- 10.1029/97RG00426 is OK
- 10.1016/0377-0273(90)90082-Q is OK
- 10.1002/esp.1127 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[crvernon]

👋 @jakelangham, @mdpiper, and @jatkinson1000 - This is the review thread for the paper. All of our communications will happen here from now on.

Please read the "Reviewer instructions & questions" in the first comment above.

Both reviewers have checklists at the top of this thread (in that first comment) with the JOSS requirements. As you go over the submission, please check any items that you feel have been satisfied. There are also links to the JOSS reviewer guidelines.

The JOSS review is different from most other journals. Our goal is to work with the authors to help them meet our criteria instead of merely passing judgment on the submission. As such, the reviewers are encouraged to submit issues and pull requests on the software repository. When doing so, please mention #6079 so that a link is created to this thread (and I can keep an eye on what is happening). Please also feel free to comment and ask questions on this thread. In my experience, it is better to post comments/questions/suggestions as you come across them instead of waiting until you've reviewed the entire package.

We aim for the review process to be completed within about 4-6 weeks but please make a start well ahead of this as JOSS reviews are by their nature iterative and any early feedback you may be able to provide to the author will be very helpful in meeting this schedule.

[jatkinson1000]

Review checklist for @jatkinson1000

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the https://github.com/jakelangham/kestrel/?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@jakelangham) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
• Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• A statement of need: Does the paper have a section titled 'Statement of need' that clearly states what problems the software is designed to solve, who the target audience is, and its relation to other work?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[mdpiper]

Review checklist for @mdpiper

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the https://github.com/jakelangham/kestrel/?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@jakelangham) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
• Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• A statement of need: Does the paper have a section titled 'Statement of need' that clearly states what problems the software is designed to solve, who the target audience is, and its relation to other work?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[jatkinson1000]

@jakelangham a couple of points as I work through this:

• I had to do some work to run the tests and have opened issue Test script failure on mac jakelangham/kestrel#12
• The web docs have no information about running the tests (only the README.md).
  Could you repeat the testing info on the web docs please?
• Similarly, the contribution guidelines are only available on the web documentation.
  Consider adding a short section (even if just a link) in the GitHub README.md
• Whilst there is a statement of need it is very brief.
  Consider expanding it slightly with more description. This should also help in making the software discoverable.
  Consider also adding tags and a website link to the GitHub 'about'.
• There is no API or subroutine documentation as far as I can tell.
  I suppose the argument is that this is designed to be used as complete code with varying input files (which are very well documented)?
  If you want contributions/development consider more detailed API documentation using something such as FORD, though I understand this may be be beyond the scope of this review.

I'll now read the paper in more detail and follow up with related comments.

[jakelangham]

@jatkinson1000 I'll work through these in due course.

I actually didn't realise a statement of need was required for the docs, but it makes complete sense.

Regarding API documentation, it would be good to clarify this before proceeding much further and to get your opinion. We thought about this issue before submission and came to the view that an independent auto-generated API documentation was a bit too heavy duty for our purposes. While it is a sizeable codebase, the control flow is pretty linear and the routines that are 'library-like' in their design are probably in the minority. This is my own prejudice, but I have seen a fair few research codes where the auto-generated API docs were totally unhelpful compared with just reading the source code.

I remember reading somewhere in the JOSS docs that for Fortran/C++ codes, having separate API documentation was optional (but encouraged), provided that the source code was well commented. So at the time we made the decision to concentrate on improving our source, since that seemed like a more obvious benefit to us, rather than spending time on a more formal API. We were aiming to make sure every module had a explanatory header + each of the most important routines, so hopefully you should find that this is the case. Let me know whether you think this is sufficient.

[jatkinson1000]

@jakelangham with regards to the paper:

• Not super important, but it is not clear to me why the project is called kestrel.
  It does not appear to be an acronym. Explaining this would be nice, and I feel somewhat useful.
• Line 41 there is an issue with reference Iverson2015
• I don't understand the date range in reference Mergili (2014-2023). Is this a typo/bibtex error?
• There are several alternative codes listed, including a number which are open source.
  The principal argument for kestrel seems to be that 'others are not well documented'. I would really like to see justification beyond this - why did you choose to create a new model rather than contributing to improve the documentation of an existing open-source model?
  This is made clearer from line 91, but I suggest restructuring to make it clear when talking about other codes that kestrel has different physics (Langham et al. (2023)) to improve morphodynamic modelling and ease of use. This is, in my view, the main motivation.
  As far as I can tell this is companion software to a new modelling approach described in Langham et al. (2023), and hence not available in the other codes.
  Being better documented than others is, to me, a corollary of this being quality research software, not a primary motivation.
• The figure here provides a really nice illustration of the concepts discussed in the theoretical background. Consider adding it to the paper.
• The final sentence of the penultimate paragraph (starting line 98 "These include...") doesn't read right to me and seems out of place. What is "These" referring to?
• When describing the 'many free parameters' perhaps refer to the online input documentation which has longer description of these?
• The paper can, at times, sound a little defensive of the fact that kestrel is more simple than other codes.
  Perhaps include a brief point about the importance of reduced order modelling for physical understanding (you do hint at this to a degree). I have been in a similar situation with codes I have written so am familiar.

Overall I think this is well-written and organised software, and it is clearly a significant piece of work. I am more than happy to recommend publication in JOSS subject to resolving the minor issues raised above, the points which I believe will strengthen the paper, and any comments from @mdpiper.

[jatkinson1000]

Regarding API documentation, it would be good to clarify this before proceeding much further and to get your opinion. We thought about this issue before submission and came to the view that an independent auto-generated API documentation was a bit too heavy duty for our purposes. While it is a sizeable codebase, the control flow is pretty linear and the routines that are 'library-like' in their design are probably in the minority. This is my own prejudice, but I have seen a fair few research codes where the auto-generated API docs were totally unhelpful compared with just reading the source code.

@jakelangham Yep, I agree, and I don't think it is necessary to add full API documentation here to satisfy review.
I have taken a look at the source files and they are very well commented, in my opinion, and should allow users that wanted to adapt the code in detail to get started.

That said, it is indeed encouraged, useful as projects/collaborators grow (speaking from experience with large climate models...), and easier to get on top of the sooner you start! I also feel when done well for appropriate routines/functions it can be a useful tool, but like many things it can be done badly! So do perhaps consider it in the future 😃

[jakelangham]

@jatkinson1000 A few updates...

@jakelangham a couple of points as I work through this:

* [ ]  I had to do some work to run the tests and have opened issue [Test script failure on mac jakelangham/kestrel#12](https://github.com/jakelangham/kestrel/issues/12)

jakelangham/kestrel@4a3799b fixes this I believe.

* [ ]  The web docs have no information about running the tests (only the README.md).
  Could you repeat the testing info on the web docs please?

Done, in jakelangham/kestrel@f80a288

* [ ]  Similarly, the contribution guidelines are only available on the web documentation.
  Consider adding a short section (even if just a link) in the GitHub README.md

Done, in jakelangham/kestrel@7a7c83c

[jakelangham]

* [ ]  Whilst there _is_ a statement of need it is very brief.
  Consider expanding it slightly with more description. This should also help in making the software discoverable.
  Consider also adding tags and a website link to the GitHub 'about'.

@jatkinson1000 We have updated the github README.md now and added some tags to address this suggestion.

[jakelangham]

@jatkinson1000 See replies below...

@jakelangham with regards to the paper:

* [ ]  Not super important, but it is not clear to me why the project is called `kestrel`.
  It does not appear to be an acronym. Explaining this would be nice, and I feel somewhat useful.

There isn't really a scientific reason for the name choice. But it's typical to view simulation data from a bird's-eye perspective. Kestrels spend a lot of time hovering in place when they're hunting so it felt appropriate to me, amongst other choices. Not sure I want to include that in the paper though.

* [ ]  Line 41 there is an issue with reference `Iverson2015`

Should be fixed by jakelangham/kestrel@ec77d54.

* [ ]  I don't understand the date range in reference `Mergili (2014-2023)`. Is this a typo/bibtex error?

jakelangham/kestrel@ee06349 removes the 2014- part. This is one of several website references I included when citing alternative codes and to be honest, I don't know what the right convention is for the year of publication. Listing them all as 2023 doesn't feel quite right when some codes have been around for a decade or so.

* [ ]  There are several alternative codes listed, including a number which are open source.
  The principal argument for kestrel seems to be that 'others are not well documented'. I would really like to see justification beyond this - why did you choose to create a new model rather than contributing to improve the documentation of an existing open-source model?
  This is made clearer from line 91, but I suggest restructuring to make it clear when talking about other codes that kestrel has different physics (Langham et al. (2023)) to improve morphodynamic modelling and ease of use. This is, in my view, the main motivation.
  As far as I can tell this is companion software to a new modelling approach described in Langham et al. (2023), and hence not available in the other codes.
  Being better documented than others is, to me, a corollary of this being quality research software, not a primary motivation.

I've tried to address this in jakelangham/kestrel@61aa2b3. My inclination was to preserve the 'line 91' paragraph as is, since it follows the description of the equations, but highlight up front earlier that the model framework and scheme are new. It is difficult to go in to much more detail without making things very technical, which I think is better suited to the companion article that we refer to.

* [ ]  The final sentence of the penultimate paragraph (starting line 98 "These include...") doesn't read right to me and seems out of place. What is "These" referring to?

It's meant to follow directly on from (2) in the last sentence. Perhaps jakelangham/kestrel@776da5a makes it easier to scan?

* [ ]  When describing the 'many free parameters' perhaps refer to the online input documentation which has longer description of these?

Done - jakelangham/kestrel@7ec1577

* [ ]  The paper can, at times, sound a little defensive of the fact that kestrel is more simple than other codes.
  Perhaps include a brief point about the importance of reduced order modelling for physical understanding (you do hint at this to a degree). I have been in a similar situation with codes I have written so am familiar.

I've reworded things a bit here and there to try and address this - for example in jakelangham/kestrel@32ea8c5 and elsewhere - see what you think.

The only additional comment to address is the inclusion of the schematic figure from the docs. The figure itself would need to be modified a little to align it with the paper. I'm not against this in principle, assuming it doesn't conflict with any length requirements, but would prefer to wait for @mdpiper's review before doing this.

[jatkinson1000]

Thanks @jakelangham, that's looking good.

jakelangham/kestrel@ee06349 removes the 2014- part. This is one of several website references I included when citing alternative codes and to be honest, I don't know what the right convention is for the year of publication. Listing them all as 2023 doesn't feel quite right when some codes have been around for a decade or so.

Right, I follow. My understanding is that you cite the 'date accessed' for web resources. Ideally there would be a JOSS/GMD paper or repository with a DOI you could also cite, but these are not common for older (and indeed many current 😢) codes. Here I would go with 2014 if it hasn't changed since then, or 2023 if it has. Looking at avaflow it has release numbers, so I would add that to the citation with date 2023 to be clear what you are comparing this work to.

The figure itself would need to be modified a little to align it with the paper. I'm not against this in principle, assuming it doesn't conflict with any length requirements, but would prefer to wait for @mdpiper's review before doing this.

I personally feel it would greatly improve the readability of the paper, but happy to wait for @mdpiper 's opinion.

I've tried to address this in jakelangham/kestrel@61aa2b3. My inclination was to preserve the 'line 91' paragraph as is, since it follows the description of the equations, but highlight up front earlier that the model framework and scheme are new.

I agree with not being too technical early on, but my issue at the moment is that when reading the paper it comes across that the principal reason for developing kestrel is better documentation and an inability to understand other models.
In reality I think the case is that kestrel models different physics to the alternatives, and this is why a new code has been written.
I believe it would greatly help the paper to make this clear when introducing the other models - you can leave the technical discussion of the physics until later, but a layperson's description something like "kestrel is capable of simulating a wide range of flow types from fluid to granular, not possible with a single alternative code, and implements the new modelling approach defined in Langham (2023) and expanded upon below" (this may not be quite correct as I am not overly familiar, but you get the idea).
I would also put this ahead of the comments on documentation as I think it is a more important motivation.

[jakelangham]

@jatkinson1000 Ok, I take the point - it should be possible to rewrite closer to what you're suggesting, with the caveat that its difficult to compare all these codes directly. The phrase about documentation could even be removed to be honest. Like the figure issue, I think I'll park this for now and come to it with a fresh perspective when addressing the next round of review comments.

[jakelangham]

@editorialbot generate pdf

[editorialbot]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[jakelangham]

@crvernon I've done as you suggested and checked the pdf draft over. Hopefully this fixes things?

[crvernon]

@editorialbot recommend-accept

[editorialbot]

Attempting dry run of processing paper acceptance...

[editorialbot]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.5194/gmd-2023-80 is OK
- 10.5194/egusphere-2023-1301 is OK
- 10.1016/j.jvolgeores.2004.06.014 is OK
- 10.1007/978-3-030-34356-9_10 is OK
- 10.3389/feart.2020.00275 is OK
- 10.1098/rspa.2013.0819 is OK
- 10.1098/rspa.2013.0820 is OK
- 10.1029/2019JF005204 is OK
- 10.1007/s10346-021-01733-2 is OK
- 10.1016/j.coldregions.2010.04.005 is OK
- 10.1016/j.ijdrr.2022.103338 is OK
- 10.1002/2013RG000447 is OK
- 10.1061/(ASCE)0733-9429(2004)130:7(689) is OK
- 10.1017/jfm.2021.235 is OK
- 10.1017/s0022112098002250 is OK
- 10.1007/b138657 is OK
- 10.1029/97RG00426 is OK
- 10.1016/0377-0273(90)90082-Q is OK
- 10.1002/esp.1127 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

👋 @openjournals/ese-eics, this paper is ready to be accepted and published.

Check final proof 👉📄 Download article

If the paper PDF and the deposit XML files look good in openjournals/joss-papers#4909, then you can now move forward with accepting the submission by compiling again with the command @editorialbot accept

[crvernon]

@jakelangham that did the trick! Thanks!

[markwoodhouse]

@jakelangham I've just read through the proof, and all looks good to me.

[crvernon]

👋 @jakelangham

I will be unavailable from Jan. 17-29. An EiC will make the final pass on this shortly so you should be good to go from here. I will check in when I come back to make sure everything is OK if you don't already have a published paper by then!

Thanks!

[jakelangham]

Thanks, very much appreciated indeed.

[kthyng]

I'll take over from here. Here are my steps:

• Check that version was updated
• Check that software archive exists, has been input to JOSS, and title and author list look good
• Check paper

[kthyng]

@jakelangham Kudos on a really nicely written paper! Just a small fix here: jakelangham/kestrel#17

[jakelangham]

@kthyng Thanks, please note that I have taken the liberty of modifying your pull request to include an additional reference that was published recently, see jakelangham/kestrel@f0b9310

[kthyng]

@editorialbot generate pdf

[editorialbot]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[kthyng]

Ok ready to go!

[kthyng]

@editorialbot accept

[editorialbot]

Doing it live! Attempting automated processing of paper acceptance...

[editorialbot]

Ensure proper citation by uploading a plain text CITATION.cff file to the default branch of your repository.

If using GitHub, a Cite this repository menu will appear in the About section, containing both APA and BibTeX formats. When exported to Zotero using a browser plugin, Zotero will automatically create an entry using the information contained in the .cff file.

You can copy the contents for your CITATION.cff file here:

CITATION.cff

cff-version: "1.2.0"
authors:
- family-names: Langham
  given-names: Jake
  orcid: "https://orcid.org/0000-0001-9857-7016"
- family-names: Woodhouse
  given-names: Mark J.
  orcid: "https://orcid.org/0000-0002-2198-6791"
doi: 10.5281/zenodo.10477693
message: If you use this software, please cite our article in the
  Journal of Open Source Software.
preferred-citation:
  authors:
  - family-names: Langham
    given-names: Jake
    orcid: "https://orcid.org/0000-0001-9857-7016"
  - family-names: Woodhouse
    given-names: Mark J.
    orcid: "https://orcid.org/0000-0002-2198-6791"
  date-published: 2024-01-22
  doi: 10.21105/joss.06079
  issn: 2475-9066
  issue: 93
  journal: Journal of Open Source Software
  publisher:
    name: Open Journals
  start: 6079
  title: The Kestrel software for simulations of morphodynamic
    Earth-surface flows
  type: article
  url: "https://joss.theoj.org/papers/10.21105/joss.06079"
  volume: 9
title: The `Kestrel` software for simulations of morphodynamic
  Earth-surface flows

If the repository is not hosted on GitHub, a .cff file can still be uploaded to set your preferred citation. Users will be able to manually copy and paste the citation.

Find more information on .cff files here and here.

[editorialbot]

🐘🐘🐘 👉 Toot for this paper 👈 🐘🐘🐘

[editorialbot]

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

0. Check final PDF and Crossref metadata that was deposited 👉 Creating pull request for 10.21105.joss.06079 joss-papers#4939
1. Wait five minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.06079
2. If everything looks good, then close this review issue.
3. Party like you just published a paper! 🎉🌈🦄💃👻🤘

Any issues? Notify your editorial technical team...

[kthyng]

Congrats on your new publication @jakelangham! Many thanks to editor @crvernon and reviewers @mdpiper and @jatkinson1000 for your time, hard work, and expertise!!

[editorialbot]

🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
[![DOI](https://joss.theoj.org/papers/10.21105/joss.06079/status.svg)](https://doi.org/10.21105/joss.06079)

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.06079">
  <img src="https://joss.theoj.org/papers/10.21105/joss.06079/status.svg" alt="DOI badge" >
</a>

reStructuredText:
.. image:: https://joss.theoj.org/papers/10.21105/joss.06079/status.svg
   :target: https://doi.org/10.21105/joss.06079

This is how it will look in your documentation:

We need your help!

The Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

• Volunteering to review for us sometime in the future. You can add your name to the reviewer list here: https://reviewers.joss.theoj.org/join
• Making a small donation to support our running costs here: https://numfocus.org/donate-to-joss