[REVIEW]: pygen-structures: A Python package to generate 3D molecular structures for simulations using the CHARMM forcefield

[whedon]

Submitting author: @thesketh (Travis Paul Hesketh)
Repository: https://github.com/thesketh/pygen-structures
Version: v0.2.4
Editor: @richardjgowers
Reviewer: @dotsdl, @RMeli, @amandadumi
Archive: 10.5281/zenodo.3739128

Status

Status badge code:

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

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

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

1. Make sure you're logged in to your GitHub account
2. 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 @richardjgowers know.

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

Review checklist for @dotsdl

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 repository url?
• 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 (@thesketh) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

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: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?

Review checklist for @RMeli

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 repository url?
• 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 (@thesketh) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

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: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?

Review checklist for @amandadumi

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 repository url?
• 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 (@thesketh) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

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: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?

[whedon]

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @dotsdl, @RMeli, @amandadumi it looks like you're currently assigned to review this paper 🎉.

⭐ Important ⭐

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:

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

2. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/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

[whedon]

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

Error reading bibliography ./paper.bib (line 75, column 3):
unexpected "d"
expecting space, ",", white space or "}"
Error running filter pandoc-citeproc:
Filter returned error status 1
Looks like we failed to compile the PDF

[richardjgowers]

@thesketh looks like three's an issue with the bibtex

[thesketh]

@whedon generate pdf

[whedon]

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

Error reading bibliography ./paper.bib (line 75, column 3):
unexpected "d"
expecting space, ",", white space or "}"
Error running filter pandoc-citeproc:
Filter returned error status 1
Looks like we failed to compile the PDF

[thesketh]

@whedon generate pdf

[whedon]

👉 Check article proof 📄 👈

[RMeli]

I had a first look at the package and have a few comments, none of which I deemed worth of its own issue for now (besides, some issues were already open). I will have a deeper look in the upcoming days, but I thought it might be useful to have some initial comments earlier.

(@richardjgowers if you prefer to see the comments in bulk do let me know and I'll adjust for next time)

Functionality

Installation

Installation is easy and described in the README. A few comments:

• Since RDKit can only be installed via conda I would remove the requirements.txt file
• I would add a second .yml defining a full environment for testing (so that the user can avoid searching for openmm installation instructions)
• Adding a dedicated "Installation" section to the README could be beneficial

Documentation

Installation

See comments above.

Detailed installation instructions could be added to the main documentation as well (the website is already in place but only the API documentation is present).

Automated Tests

Automated tests can be easily run with pytest and all pass. However, there is no test coverage displayed. Using pytest-cov I can see that some modules have rather low coverage (convenience_functions.py is at 41%). I think the test coverage metric should be added and improved for some modules.

(See also thesketh/pygen-structures#3)

Functionality Documentation

Documentation for the objects returned by different functions is often missing.

Example Usage

There is a single usage example. I think more usage examples should be added.

It would be useful to describe the different input in more details within the documentation with the help of usage examples.

(See also thesketh/pygen-structures#2; as noted there, the documentation skeleton is already in place and should be relatively straightforward to add an "Usage Examples" section)

Misc

I noticed that the CHARMM parameter files are included under pygen_structures/toppar. Is there an associated license for such files?

[richardjgowers]

Hey Rocco, thanks for the feedback, I think these points are probably good to be raised as issues too

…

On Tue, Mar 10, 2020 at 22:34, Rocco Meli ***@***.***> wrote: I had a first look at the package and have a few comments, none of which I deemed worth of its own issue for now (besides, some issues were already open). I will have a deeper look in the upcoming days, but I thought it might be useful to have some initial comments earlier. ***@***.*** <https://github.com/richardjgowers> if you prefer to see the comments in bulk do let me know and I'll adjust for next time) Functionality Installation Installation is easy and described in the README. A few comments: - Since RDKit can only be installed via conda I would remove the requirements.txt file - I would add a second .yml defining a full environment for testing (so that the user can avoid searching for openmm installation instructions) - Adding a dedicated "Installation" section to the README could be beneficial Documentation Installation See comments above. Detailed installation instructions could be added to the main documentation as well (the website is already in place but only the API documentation is present). Automated Tests Automated tests can be easily run with pytest and all pass. However, there is no test coverage displayed. Using pytest-cov I can see that some modules have rather low coverage (convenience_functions.py is at 41%). *I think the test coverage metric should be added and improved for some modules.* (See also thesketh/pygen-structures#3 <thesketh/pygen-structures#3>) Functionality Documentation Documentation for the objects returned by different functions is often missing. Example Usage There is a single usage example. *I think more usage examples should be added*. It would be useful to describe the different input in more details within the documentation with the help of usage examples. (See also thesketh/pygen-structures#2 <thesketh/pygen-structures#2>; as noted there, the documentation skeleton is already in place and should be relativelystraightforward to add an "Usage Examples" section) Misc I noticed that the CHARMM parameter files are included under pygen_structures/toppar. Is there an associated license for such files? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2157?email_source=notifications&email_token=ACGSGBZHAHOCB5EP5JVL4E3RG2565A5CNFSM4LFDODLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEONOIBA#issuecomment-597353476>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSGB4HGDUH3T6QDFDL2OTRG2565ANCNFSM4LFDODLA> .

[thesketh]

Thanks for the preliminary comments, Rocco. I'll address these as soon as I can. I think I can fix the poor coverage of convenience_functions by comparing code_to_mol and sequence_to_mol with a manually created Molecule.

The requirements.txt file is necessary for PyPI distribution. I could remove RDKit from the requirements and catch the ImportError at runtime to produce a more helpful error, but I thought this was a dirtier solution.

The toppar distribution is in the public domain, but I'll add another README in this folder explaining where the files are from, where new versions can be obtained, and what changes have been made from the standard distribution (I've noticed some issues with the D-amino acid parameters, which are fixed in the 0.2.3 branch).

Documentation for return types is missing in some cases because from __future__ import annotations is unavailable in Python 3.6, but I'll add :rtype: tags where this is the case.

[RMeli]

Thanks for clarifying the situation with toppar; the lack of license on their end is a bit strange... In the light of the forum discussion you linked, what you suggest to do sounds very reasonable.

I'm not well versed with PyPI distribution, but I have a package on PyPI without any requirements.txt. I think PyPI deployment only uses install_requires in setup.py (see here):

install_requires should be used to specify what dependencies a project minimally needs to run. When the project is installed by pip, this is the specification that is used to install its dependencies.

If I pip-install pygen_structures on a clean environment, the package is installed but neither numpy nor rdkit are (since install_requires is not specified). I think you can remove requirements.txt, add numpy to install_requires and leave rdkit installation to the user as described in the documentation (I think the error ModuleNotFoundError: No module named 'rdkit' is clear enough). Other reviewers might have different opinions and are probably more experienced with PyPI deployment, so I'd wait for their comments before making any change.

[thesketh]

Thanks for the tip about the install_requires, it seems that there's even a page on "install_requires vs requirements files". I was under the impression that requirements.txt was necessary. I think you're probably right and that deleting it is the right thing to do, but I'll hold off for now.

I think I've addressed most of your initial comments now (with the extra information added to README), but I still need to add the information to the main documentation.

[arfon]

Dear authors and reviewers

We wanted to notify you that in light of the current COVID-19 pandemic, JOSS has decided to suspend submission of new manuscripts and to handle existing manuscripts (such as this one) on a "best efforts basis". We understand that you may need to attend to more pressing issues than completing a review or updating a repository in response to a review. If this is the case, a quick note indicating that you need to put a "pause" on your involvement with a review would be appreciated but is not required.

Thanks in advance for your understanding.

Arfon Smith, Editor in Chief, on behalf of the JOSS editorial team.

[thesketh]

Thank you for your comment, @arfon . It is refreshing to see a journal which cares about its authors, editorial staff, and reviewers.

In Scotland, we are relatively unaffected (as of yet) but I implore the editor and the reviewers to take the time they need in light of the current crisis. This submission can wait, your health can not. If you have comments to make, they are appreciated, but please focus on your health first and foremost.

[amandadumi]

I am still making my way through the code, but I had another thought about the handling of the additional testing dependency. I agree that avoiding having users search for openmm installation instructions would be good. @RMeli provided this solution, which was nice!

* I would add a second `.yml` defining a full environment for testing (so that the user can avoid searching for `openmm` installation instructions)

Another way that this can be done is to define these as extras in the setup.py as described here. I just wanted to mention this since this would avoid an extra file and could then be installed from pypi as described here. What do you think, @RMeli? I haven't dealt with this first hand so I'm not sure if your approach has a benefit I am overlooking.

[RMeli]

@amandadumi I think that would be a good idea, but it seems to me that in order to install OpenMM conda is needed (with the -c omnia -c conda-forge channels).

[richardjgowers]

Iirc there was an effort to get a minimal openmm working on conda-forge... the hang up was cuda dependencies

…

On Sun, Mar 15, 2020 at 20:03, Rocco Meli ***@***.***> wrote: @amandadumi <https://github.com/amandadumi> I think that would be a good idea, but it seems to me that in order to install OpenMM <http://docs.openmm.org/latest/userguide/application.html#installing-openmm> conda is needed (with the -c omnia -c conda-forge channels). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSGB4X4PQU3WJD7KE5PLDRHUYCDANCNFSM4LFDODLA> .

[richardjgowers]

By @jaimergp On Sun, Mar 15, 2020 at 20:06, Richard Gowers <[email protected]> wrote:

…

Iirc there was an effort to get a minimal openmm working on conda-forge... the hang up was cuda dependencies On Sun, Mar 15, 2020 at 20:03, Rocco Meli ***@***.***> wrote: > @amandadumi <https://github.com/amandadumi> I think that would be a good > idea, but it seems to me that in order to install OpenMM > <http://docs.openmm.org/latest/userguide/application.html#installing-openmm> > conda is needed (with the -c omnia -c conda-forge channels). > > — > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > <#2157 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACGSGB4X4PQU3WJD7KE5PLDRHUYCDANCNFSM4LFDODLA> > . >

[RMeli]

@thesketh I didn't have enough time to dig deep into the code, but I have some comments about the paper below.

Software Paper

Statement of Need

A big chunk of Fig. 1 details "planned future work". This gives the impression that pygen-structures is incomplete and there is still a lot of work to do. I'm wondering if it would be better to focus on what the program does instead of outlining a lot of planned things that could be far away in the future. Generating coordinates for missing residues is a big project in itself and you already underline this limitation in the conclusions. @richardjgowers might have some advice on this.

Summary

I'm not sure about the term "arbitrary molecules", since you can only generate molecules from CHARMM residues and patches.

Problems with Current Workflow

• Is there a way to fit the content of the PDB file within the paper margins?

I think the problems with current workflows are very well illustrated. Despite only two packages are discussed (RDKit and MarvinSketch), I think similar problems will arise with other packages.

Future Work

I think it's great that you outline the limitation of pygen-structures compared to psfgen and possible big additions to the functionality of the software. However, I think that the documentation of the current features should be complete and not left as future work.

Dependencies

• Citations for Numpy is missing.
• Unit and integration tests should be complete and not limited.

Acknowledgements

• Is there any funding body to be acknowledged?

Misc

• It's worth adding more details to your affiliation (department, address)?
• psfgen is inconsistently written in italic

[jaimergp]

Hi! Yes, we have a functional openmm recipe on conda-forge, but still not publicly available (it's on the testing label). We have to sort out how to deal with potentially unsupported OpenCL implementations (check conda-forge/cfep#17). In the meantime, the omnia channel is needed, but as you can see in the issue this is subject to change in the near-term future.

[thesketh]

@whedon generate pdf

Thank you both for your comments! I'm aware of the attempts to get OpenMM onto conda-forge, but I use OpenMM quite extensively in my research so I'm following this as well.

@amandadumi I've addressed this now in the installation instructions (and fixed the issue you opened about the RDKit installation instructions), but sadly I don't think there's an easy way to get around using conda for the dependencies. It's a shame there isn't a tie-in between pip and conda.

@RMeli I think I've fixed some of the issues you noted with the paper now.

Statement of Need

The "Planned future work" was intended to note that there's another workflow (working with large molecules from the PDB) which currently isn't supported. I've updated the figure to state "Other software" instead. For perfectly formed PDB structures, filling missing hydrogen atoms (and even missing heavy atoms if the surrounding atoms are present) should in principle be easy, but the RDKit currently gives a segmentation fault on larger protein structures (I tried HEWL without success). I'm going to investigate using OpenBabel as a backend as well to address this, but I think it's outside the scope of this paper.

Summary

'arbitrary' has been removed.

Problems with Current Workflows

I'd like to fit the contents of the PDB inside the page margins as well, would it be best to use a line continuation character such as \ and elipses on the following line? This is the main reason why I haven't updated the PSF examples to the current format (which uses the EXT format) - they're much wider.

I've noted similar behaviour from Avogadro (correctly identifies residue, but calls both the L and D forms the L-amino name) and GaussView (behaves similarly to MarvinSketch), but have omitted these examples to avoid making the paper too long.

Future Work

Yes, you're right of course. I've updated this section to reflect this. I still think that further documentation of the polymeric structures included in CHARMM would be useful (e.g. is it possible to make triglycerides from glycerol/fatty acids? Are there glycolipid linkages defined?) but I think this may be better placed in the CHARMM documentation - CHARMM-GUI may already have some information about this.

Dependencies

These have been updated, I've added a citation for PyTest as well.

Acknowledgements

I'm a postgraduate student funded by the University of Strathclyde, but the work on this project has been done in my own time so I don't think that this is applicable here.

Misc

Is there a particular YAML field that this extra information should go under? The example papers only contain university name and department name.

Regarding italicisation, I've italicised all software packages on first invocation, but not afterwards. I couldn't see any guidelines about how best to format this. I can italicise all references to software packages if that would be more consistent

[whedon]

👉 Check article proof 📄 👈

[thesketh]

It would help if I'd pushed the changes to the flowchart.

@whedon generate pdf

[whedon]

OK. v0.2.4 is the version.

[arfon]

@whedon generate pdf

[whedon]

👉 Check article proof 📄 👈

[arfon]

@thesketh - I made a minor whitespace formatting fix in thesketh/pygen-structures#9 that it would be good to have merged before we accept and publish here.

[arfon]

@thesketh - At this point could you make a new release of this software that includes the changes that have resulted from this review. Then, please make an archive of the software in Zenodo/figshare/other service and update this thread with the DOI of the archive? For the Zenodo/figshare archive, please make sure that:

• The title of the archive is the same as the JOSS paper title
• That the authors of the archive are the same as the JOSS paper authors

I can then move forward with accepting the submission.

[thesketh]

@whedon generate pdf

[whedon]

👉 Check article proof 📄 👈

[thesketh]

Thanks for the PR, @arfon. The v0.2.4 release already contains all the changes, the Zenodo DOI is 10.5281/zenodo.3739128

[arfon]

@whedon set 10.5281/zenodo.3739128 as archive

[whedon]

OK. 10.5281/zenodo.3739128 is the archive.

[arfon]

@whedon accept

[whedon]

Attempting dry run of processing paper acceptance...

[whedon]

Reference check summary:

OK DOIs

- 10.1186/1758-2946-4-17 is OK
- 10.1017/S0033583500003966 is OK
- 10.1002/jcc.23354 is OK
- 10.1109/MCSE.2011.37 is OK
- 10.1371/journal.pcbi.1005659 is OK
- 10.1021/acs.jcim.5b00654 is OK
- 10.1016/0263-7855(96)00018-5 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

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

Check final proof 👉 openjournals/joss-papers#1418

If the paper PDF and Crossref deposit XML look good in openjournals/joss-papers#1418, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.

@whedon accept deposit=true

[arfon]

@whedon accept deposit=true

[whedon]

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

[whedon]

🐦🐦🐦 👉 Tweet for this paper 👈 🐦🐦🐦

[whedon]

🚨🚨🚨 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.02157 joss-papers#1419
1. Wait a couple of minutes to verify that the paper DOI resolves https://doi.org/10.21105/joss.02157
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...

[arfon]

@dotsdl, @RMeli, @amandadumi - many thanks for your reviews here and to @richardjgowers for editing this submission ✨

@thesketh - your paper is now accepted into JOSS ⚡🚀💥

[whedon]

🎉🎉🎉 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.02157/status.svg)](https://doi.org/10.21105/joss.02157)

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

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

This is how it will look in your documentation:

We need your help!

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://joss.theoj.org/reviewer-signup.html
• Making a small donation to support our running costs here: https://numfocus.org/donate-to-joss

[thesketh]

Many thanks to @dotsdl, @RMeli, and @amandadumi for their reviews - the project is definitely in a better shape thanks to their helpful comments and suggestions - and to @richardjgowers and @arfon for editing 😁

[dotsdl]

Happy to do it @thesketh! I took a look at the documentation and I think it now looks great. Thank you for putting this together! 🎆

[RMeli]

It's been a pleasure to review this work, congratulations @thesketh !