[REVIEW]: DORiE: A discontinuous Galerkin solver for soil water flow and passive solute transport based on DUNE

Submitting author: !--author-handle-->@peanutfun@meg-simula<!--end-editor-- Reviewer: @gassmoeller, @pratikvn Archive: 10.5281/zenodo.3997152

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

Status

Status badge code:

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

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

@gassmoeller & @pratikvn, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

Make sure you're logged in to your GitHub account
Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

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

✨ Please try and complete your review in the next six weeks ✨

Review checklist for @gassmoeller

Conflict of interest

[x] 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

[x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

[x] Repository: Is the source code for this software available at the repository url?
[x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
[x] Contribution and authorship: Has the submitting author (@peanutfun) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

[x] Installation: Does installation proceed as outlined in the documentation?
[x] Functionality: Have the functional claims of the software been confirmed?
[x] 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

[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
[x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
[x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
[x] Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
[x] 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

[x] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] State of the field: Do the authors describe how this software compares to other commonly-used packages?
[x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
[x] 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?

Review checklist for @pratikvn

Conflict of interest

[x] 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

[x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

[x] Repository: Is the source code for this software available at the repository url?
[x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
[x] Contribution and authorship: Has the submitting author (@peanutfun) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

[x] Installation: Does installation proceed as outlined in the documentation?
[x] Functionality: Have the functional claims of the software been confirmed?
[x] 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

[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
[x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
[x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
[x] Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
[x] 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

[x] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] State of the field: Do the authors describe how this software compares to other commonly-used packages?
[x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
[x] 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?

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @gassmoeller, @pratikvn it looks like you're currently assigned to review this paper :tada:.

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

:star: Important :star:

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

Set yourself as 'Not watching' https://github.com/openjournals/joss-reviews:

watching

You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

notifications

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

@whedon commands

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

@whedon generate pdf

PDF failed to compile for issue #2313 with the following error:

Can't find any papers to compile :-(

@gassmoeller @pratikvn Thanks again for agreeing to review. Checklists have been generated for each you above, ready for your review :-)

@whedon generate pdf from branch joss-paper

Attempting PDF compilation from custom branch joss-paper. Reticulating splines etc...

Here are some things you can ask me to do:

# List Whedon's capabilities
@whedon commands

# List of editor GitHub usernames
@whedon list editors

# List of reviewers together with programming language preferences and domain expertise
@whedon list reviewers

EDITORIAL TASKS

# Compile the paper
@whedon generate pdf

# Compile the paper from alternative branch
@whedon generate pdf from branch custom-branch-name

# Ask Whedon to check the references for missing DOIs
@whedon check references

# Ask Whedon to check repository statistics for the submitted software
@whedon check repository

@whedon check references

@peanutfun, A very nice library! I have a few comments:

You list four authors for your paper. Among the contributors on your repository page, I see only three of the contributors. I believe that the last author is a supervisor. Can you confirm that the last author provided specific non-code contributions/active project direction related to your code ? This is a requirement from the JOSS authorship guidelines.
I really like that the software is available through docker.
It could be nice to have it as a spack package as well. I understand that you have a strong dependency on DUNE and DUNE does not yet seem to be available as a spack package.

@meg-simula , Would there be a way to check the references through whedon ? I guess the command does not work now because the paper and the .bib file are in a different branch.

It could be nice to have it as a spack package as well. I understand that you have a strong dependency on DUNE and DUNE does not yet seem to be available as a spack package.

Perhaps I could comment on this. There is indeed some recent initial support for DUNE in spack so the idea is not completely out of the range. I will give it a try this week. Thank you for the suggestion.

EDIT: See issue #195

@pratikvn, thank you for your quick feedback!

[...] I believe that the last author is a supervisor. Can you confirm that the last author provided specific non-code contributions/active project direction related to your code ? [...]

The last author Ole Klein made contributions to both project directions and code. He developed the initial version of the essential Richards DG local operator (see dune/dorie/models/richards/local_operator_DG.hh) and he provided continuous support for numerical implementations, and verifying and testing computation results. If desired and possible, we could add a "Author Contributions" section to the paper for clarification.

I really like that the software is available through docker.

It could be nice to have it as a spack package as well. [...]

I have no experience with spack myself but it seems like we could get help on that by the DUNE devs. As maintaining a spack configuration will cause an additional support overhead, I would personally only see it as "nice to have".

This actually relates to your second point. With the current installation instructions and Docker support, we think that we cover most of the experience levels of possible users and developers of DORiE: Inexperienced users can simply use a Docker image to run the application, possibly even on a server cluster. Inexperienced developers will likely have a nearly "clean system" as envisaged in our README.md, so they can simply follow the step-by-step installation instructions. Experienced developers, on the other hand, can use these instructions and the dependency list to install DORiE on their machines with possibly customized setups.

If the installation of DORiE causes problems, I would therefore primarily work on clarifying the instructions in the README.md before tending to additional installation support, e.g. via spack.

@SoilRos: Thanks for pitching in! 😊

@peanutfun ,

The last author Ole Klein made contributions to both project directions and code. He developed the initial version of the essential Richards DG local operator (see dune/dorie/models/richards/local_operator_DG.hh) and he provided continuous support for numerical implementations, and verifying and testing computation results. If desired and possible, we could add a "Author Contributions" section to the paper for clarification.

I believe active project direction and contributions to the code are sufficient. I don't think an "Author Contributions" section is necessary. Thanks for clarifying this.

I have no experience with spack myself but it seems like we could get help on that by the DUNE devs. As maintaining a spack configuration will cause an additional support overhead, I would personally only see it as "nice to have".

Yes, this was just a suggestion. One of the main reasons I suggest adding a spack package is that HPC users can install it on their cluster themselves (which they do not have root access to and hence cannot use docker) very easily and the fact that dune already has a spack package should simplify the process greatly.

The docker installation went smooth for me. But installation by source is definitely more involved. The dune-installer with dune control definitely helps, but I guess the fact that the list of dependencies is quite large makes installation quite lengthy. Nevertheless, the instructions on README.md look complete to me and I did not have any problems installing and running dorie.

To make the installation by source slightly easier, I would suggest adding a bootstrapping script. Assuming that all the basic library dependencies (g++, hdf5, python3 etc.. ) are satisfied, you could provide a script that clones the dune modules into a directory, switches to the required release branch for all of them, clones dorie and calls the ...dunecontrol all install script to install all of dune and dorie. I think simpler installation by source makes open source contributions and hence collaborations easier.

@pratikvn, I'm glad we could resolve the author issue and that you had no trouble building and running DORiE.

Thank you for elaborating on the use cases of spack. I realize that missing root privileges is an issue we have not considered much. Supporting such a setup would be a nice addition. At your discretion, however, we would consider the associated issue dorie#195 as non-essential for this review.

To make the installation by source slightly easier, I would suggest adding a bootstrapping script.

Cloning the modules is indeed the worst described part of the installation process. I like your suggestion of using a script for this part (only). Additionally, I propose to add a DUNE buildsystem options file, which would simplify the call to dunecontrol instead of automating it. This way, users can more easily specify additional CMake variables required for their setup. I would not add instructions on cloning DORiE, as executing the script locally usually implies that somebody cloned it already.

The installation process would then change as follows:

After installing the prerequisites, users clone DORiE.
Cloning the required DUNE modules (currently step 5) is replaced by calling a bash script like
```
bash dorie/clone_dune_modules.bash
```
For building the DUNE stack including DORiE (currently step 7), users execute
```
./dune-common/bin/dunecontrol  --opts=dorie/build.opts --module=dorie all
```

@peanutfun,

At your discretion, however, we would consider the associated issue dorie#195 as non-essential for this review.

Yes, sure. I don't believe that it is essential for this review.

Cloning the modules is indeed the worst described part of the installation process. I like your suggestion of using a script for this part (only). Additionally, I propose to add a DUNE buildsystem options file, which would simplify the call to dunecontrol instead of automating it. This way, users can more easily specify additional CMake variables required for their setup. I would not add instructions on cloning DORiE, as executing the script locally usually implies that somebody cloned it already.

This sounds reasonable to me. The new installation process does look a lot more simpler. Thanks.

@meg-simula , Would there be a way to check the references through whedon ? I guess the command does not work now because the paper and the .bib file are in a different branch.

Let me check and get back to you.

@whedon check references from branch joss-paper

Attempting to check references... from custom branch joss-paper

Reference check summary:

OK DOIs

- doi:10.1093/imanum/drm050 is OK
- 10.1016/j.advwatres.2012.05.008 is OK
- 10.11588/ans.2016.100.26526 is OK
- 10.1007/978-3-642-22980-0 is OK
- 10.1007/s10596-014-9426-y is OK
- 10.1016/j.crma.2007.10.036 is OK
- 10.1002/nme.2579 is OK
- 10.2136/vzj2019.01.0001 is OK
- 10.1016/j.advwatres.2007.02.007 is OK
- 10.2136/sssaj2017.02.0058 is OK
- 10.1016/j.advwatres.2011.03.007 is OK

MISSING DOIs

- None

INVALID DOIs

- None

@peanutfun, I have finished my review of DORiE and think it will make a fine publication in JOSS. You follow best practices and the application is well documented. I agree with @pratikvn that a script that simplifies the installation and a spack recipe would be beneficial, although not absolutely necessary.

I found no major obstacles to publication, but would like to make two suggestions and have one question, and one comment:

Suggestion. You already build a Docker image that only contains the Dune environment necessary to compile DORiE (dorie/dune-env), which I like a lot. I think it is worth advertising this in a sentence in the documentation (e.g. at the end of this section https://hermes.iup.uni-heidelberg.de/dorie_doc/master/html/markdown/README.html#download-docker-image). This also somewhat alleviates the need for a simpler local installation procedure, because for an intermediate user who wants to lightly modify DORiE that might be the simplest way to set up a development version.
Suggestion. You may want to consider how to add instructions for how to cite DORiE. I suppose you want users to cite the JOSS article, but that should be advertised in several places, like the README.md, the main page of the documentation and website, and ideally also in a machine readable file like the citation file format (https://citation-file-format.github.io/), or a CodeMeta file (https://codemeta.github.io/). Since the JOSS doi is already reserved you can already add this information in the joss-paper branch of DORiE.
Question. The installation procedure mentions that DORiE can use ParMetis for parallel models, but I found no information about how to run DORiE in parallel. Did I miss a page, or is this just experimental at the moment?
Comment. I generally found DORiE's code to be nicely readable. I would encourage you to proceed with https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/merge_requests/203, a common coding style makes source code so much easier to read and prevents bugs. Also as in any software there are always things to improve. One of the patterns I saw in the files I looked into (of course not a full review of all files) is that you occasionally use abbreviated variable names that are shortened so much that they require additional comments and make subsequent code harder to understand (thus defeating the purpose of shortening the name to make the code more readable). For an example compare the following two lines (original line in https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/blob/master/dune/dorie/model/richards/richards.cc#L96):
```
// --- Grid Function Space ---
this->_log->trace("Setting up GridFunctionSpace");
gfs = std::make_shared<GFS>(GFSHelper::create(gv));
gfs->name("matric_head");
cc = std::make_unique<CC>();
Dune::PDELab::constraints(*gfs,*cc,false);
```

...

// --- Solution Vector --- // u = std::make_shared(*gfs,.0);

...

Dune::PDELab::interpolate(finitial, gfs, *u);

vs

Dune::PDELab::interpolate(finitial, grid_function_space, *solution_vector);


I am aware that there will always be lines that do not follow all best practices so this is not a recommendation to fix this particular instance for this review. Just something to keep in mind for the future development of DORiE in general.

I liked this software, keep up the good work!

@gassmoeller, thanks a lot for your quick review and positive feedback!

Suggestion. You already build a Docker image that only contains the Dune environment necessary to compile DORiE (dorie/dune-env), which I like a lot. I think it is worth advertising this in a sentence in the documentation [...]

Sounds good! We did not do so before because we felt that somebody who can manage development through a mounted Docker container will also manage the manual installation process and end up with a much more capable development environment. Anyway, I'll add this through an MR.

Suggestion. You may want to consider how to add instructions for how to cite DORiE. [...]

I very much like the Citation File Format and already raised an issue in the DORiE repository, see dorie#199.

Question. The installation procedure mentions that DORiE can use ParMetis for parallel models, but I found no information about how to run DORiE in parallel. Did I miss a page, or is this just experimental at the moment?

DUNE generally supports parallelism via MPI, depending on the actual grid and solver setup. We built DORiE to be run in parallel on a best-effort basis. As we did not want to support both sequential and parallel builds simultaneously, we instruct users to always install OpenMPI, which is technically not required to build DUNE. Therefore, any build of DORiE is capable of running the application in parallel. The same is true for the Docker image.

Parallel execution currently is only supported on structured rectangular grids, that is, with the config file parameters grid.gridType = rectangular and adaptivity.policy = None. You can control it via the -p/--parallel option for the run command of the command line interface. There are system tests called parallel-reference<-compare>, where we check if the results of sequential and parallel runs with the same configuration yield the same results. We are still working on bringing parallelism to unstructured and even adaptive grids, see dorie!9.

In terms of the documentation, the feature is indeed somewhat hidden. Should we advertise it in the Feature Overview and/or mention it in the README.md?

Comment. [...] you occasionally use abbreviated variable names that are shortened so much that they require additional comments and make subsequent code harder to understand [...]

This is true, especially for the file you mention. In most of these instances, the naming convention then follows usual code practices of the DUNE-PDELab package, see https://gitlab.dune-project.org/pdelab/dune-pdelab/-/blob/master/dune/pdelab/test/test-transport-ccfv.cc#L231 for an example. The rationale behind some of the names is following the symbols of the numerical problem formulation. For example, the mathematical symbol for the solution (vector) typically is x or u. Similar things happen in the local operators (e.g., https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/blob/master/dune/dorie/model/richards/local_operator_DG.hh), where the local test function is denoted by the variable phi instead of test_func, or similar.

We have a certain interest in keeping the naming convention close to the one used in PDELab because that simplifies communicating code with the PDELab devs. However, you are right about the issue that the code might become difficult to read for people who are less involved. As some of the files also have a (historically grown) bad formatting, I opened dorie#200 to suggest a few changes and discuss the issue with the other DORiE devs.

I too found no major obstacles for publishing this paper. Some final comments:

The documentation is thorough and easy to understand. You already have one example, the Infiltration in Homogeneous Medium within the cookbook section of your documentation. It might also be nice to have a separate section with a few more examples with code and explanations. If you have some papers that you have published with dorie, then you could even use those as your examples. This enhances the quality of your papers and also showcases your reproducibility.
Regarding the coding conventions, I see that you already have a MR addressing that. To simplify and unify your coding styles I would recommend something similar to a hook that you already discuss in the PR. You can have a look at https://github.com/kbenzie/git-cmake-format which integrates clang-format into git and the developer would have to stage their files, call make format, and all the staged files are format with clang-format and unstaged after formatting. This makes sure that the developer can only commit after they have formatted their files. See an updated version of that repo here https://github.com/ginkgo-project/git-cmake-format.

In terms of the documentation, the feature is indeed somewhat hidden. Should we advertise it in the Feature Overview and/or mention it in the README.md?

If the feature is available and usable for a subset of problems, then I would definitely advertise it in the Feature Overview of your documentation but also mention that some features ( like unstructured grids) are a work in progress.
Lastly, I would suggest that you have a look at the xSDK policies, which are a set of guidelines that help you in interfacing with other libraries if needed and also help in making your software sustainable. As you depend on Dune and already have quite a high code quality, I think you already satisfy many of the requirements. But if it is possible and not too much work, then I would highly recommend trying to satisfy atleast all the Mandatory policies listed.
As you already use gcovr and code coverage to generate the code coverage reports, it might be worth adding a badge showing your coverage status.

Overall, I liked the software and the paper and commend your efforts.

@pratikvn, thanks again for your comments! Let me answer them one by one...

[...] It might also be nice to have a separate section with a few more examples with code and explanations. If you have some papers that you have published with dorie, then you could even use those as your examples.

The idea of the Cook Book section is to have real use-case examples, which will eventually cover all the (more technical) information given in the manual. I'm not entirely sure what you mean by "code and explanations". For the internals of the C++ code, we provide the Doxygen documentation, which is aimed at developers. Here we explain how the internals of DORiE work, which is intended to help modifying the code base or integrating it into another project. The latter is what was done for our latest publication, https://doi.org/10.1002/vzj2.20040, which is also featured in the JOSS paper. For this we extended DORiE with an interface for the data assimilation framework we used. The interface is publicly available in dorie!134. However, we cannot publish the entire code base for the paper because the data assimilation framework has not been published.

[...] To simplify and unify your coding styles I would recommend something similar to a hook that you already discuss in the PR. You can have a look at https://github.com/kbenzie/git-cmake-format [...]

Thank you for this suggestion. I personally prefer automation through a git commit hook. Build systems like CMake are designed to construct and modify a build directory tree from a source tree. Modifying the source tree with the build system seems invasive to me. Git, on the other hand, only manages the source tree, so it seems to me like enforcing a format style through it is the "cleaner" approach.

If the feature is available and usable for a subset of problems, then I would definitely advertise it in the Feature Overview of your documentation but also mention that some features ( like unstructured grids) are a work in progress.

I added more information on the capabilities of DORiE (and their respective caveats) in dorie!209.

Lastly, I would suggest that you have a look at the xSDK policies, which are a set of guidelines that help you in interfacing with other libraries if needed and also help in making your software sustainable. [...]

I was not aware of this project and its community. I will consider registering DORiE as "xSDK compatible" package.

As you already use gcovr and code coverage to generate the code coverage reports, it might be worth adding a badge showing your coverage status.

I added a coverage badge to the DORiE GitLab repository.

@pratikvn, @gassmoeller, I'm very happy about your feedback and suggestions! To move forward, I want to make sure we are keeping track of all issues you consider crucial for this review. We created a milestone listing all such issues and associated merge requests: https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/milestones/6. Here's a checklist of your proposals that I understood to be required:

[x] Add a script for cloning DUNE modules and simplify calling the dunecontrol script: dorie#197, dorie!205
[ ] Add information on how to cite DORiE: dorie#199, included in dorie!198
[x] Propose using the DUNE environment Docker image for code development: dorie!209
[x] Feature adaptive grid refinement and parallel execution, as well as their caveats, in the user documentation: dorie!209

Please check if this list is complete and tell me if there's anything else we need to take care of.

Finally, I did some cosmetic updates to the JOSS paper:

Fixed formulations in lines 74 and 75 of paper.md:
- "generated within the DORiE" -> "generated within DORiE"
- "The simulation output is written in VTK files" -> "The simulation output is provided as VTK files"
Removed unused reference from bibliography.
Removed redundant doi: from a DOI entry.
Updated reference to "Bauser et al. 2020" because the article was published.

I'll compile the latest version now.

@whedon generate pdf from branch joss-paper

Attempting PDF compilation from custom branch joss-paper. Reticulating splines etc...

Please check if this list is complete and tell me if there's anything else we need to take care of.

Looks good to me. Thanks for adding the changes!

Please check if this list is complete and tell me if there's anything else we need to take care of.

Yes, looks good. Once the issues and merge requests in your milestone have been addressed I am ok with moving forward with this publication.

About your earlier questions about code style: Yes balancing consistency with upstream projects and readability is always an issue and there is no perfect solution. I appreciate that you started a discussion and are willing to consider changes, you as the developers are in the best position to judge which changes are useful and which would break the consistent naming scheme with DUNE.

Great, thank you! We merged dorie!209 into master and now only need to patch v2.0-stable with the additions. I'm not entirely sure when to merge the JOSS paper and the citation file in dorie!198, though, particularly because I wanted to include the Zenodo archive DOI in the citation file.

@meg-simula, (only) supposing the review was concluded, the next step would be archiving the tested version of the software at Zenodo, right? Should this version and the resulting Zenodo archive contain the JOSS paper as well, or should I merge it into the master and release branches afterwards?

We have a patch release with the requested changes and additions ready for merging: dorie!212. This will then constitute the final reviewed version of DORiE we want to hand in. We are only unsure if the JOSS paper and/or the CITATION.cff file should be included in the patch release. I would propose that we first deploy the version to Zenodo (without the paper), then update the paper and finalize the citation file, and then merge both into master. But I'm not sure if this is the desired procedure for a JOSS publication.

:wave: @peanutfun - I just heard from @meg-simula that she's currently on vacation until early August and doesn't have access to her GitHub account until she's back online. Apologies for the delay here!

👋 @arfon, thank you for letting us know!

@meg-simula, enjoy your vacation! We are looking forward to wrapping this up when you are back 😊

/ooo July 28 until August 10

Thanks for your understanding @peanutfun - I dropped my phone in the Skagerak which, combined with two-factor authorization, made logging into GitHub terribly difficult :laughing: I will take a look at this when I'm back on August 10 if not sooner.

@whedon generate pdf

@whedon check references

PDF failed to compile for issue #2313 with the following error:

Can't find any papers to compile :-(

@whedon generate pdf from branch joss-paper

Attempting PDF compilation from custom branch joss-paper
. Reticulating splines etc...

PDF failed to compile for issue #2313 with the following error:

error: pathspec 'joss-paper ' did not match any file(s) known to git. Can't find any papers to compile :-(

@whedon check references from branch joss-paper

Attempting to check references... from custom branch joss-paper

@whedon generate pdf from branch joss-paper

Attempting PDF compilation from custom branch joss-paper
. Reticulating splines etc...

PDF failed to compile for issue #2313 with the following error:

error: pathspec 'joss-paper ' did not match any file(s) known to git. Can't find any papers to compile :-(

@peanutfun Thanks for your patience on this submission. Would you know of any changes to the branch structure - making it hard for whedon to find the paper?

@whedon generate pdf from branch joss-paper

Attempting PDF compilation from custom branch joss-paper. Reticulating splines etc...

openjournals / joss-reviews