[REVIEW]: VTUFileHandler: A VTU library in the Julia language that implements an algebra for basic mathematical operations on VTU data

[editorialbot]

Submitting author: @baxmittens (maximilian bittens)
Repository: https://github.com/baxmittens/VTUFileHandler
Branch with paper.md (empty if default branch):
Version: v0.2.0
Editor: @jbytecode
Reviewers: @dmbates, @mkitti
Archive: 10.5281/zenodo.6576155

Status

Status badge code:

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

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

@dmbates & @mkitti, 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 @jbytecode 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 @mkitti

📝 Checklist for @dmbates

[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.05 s (370.7 files/s, 30699.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Julia                           11            126             47            850
XML                              2              0              0            166
Markdown                         2             30              0            133
TeX                              1              3              0             36
TOML                             1              2              0             15
-------------------------------------------------------------------------------
SUM:                            17            161             47           1200
-------------------------------------------------------------------------------


gitinspector failed to run statistical information for the repository

[editorialbot]

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

OK DOIs

- 10.23919/EuCAP.2017.7928679 is OK
- 10.1109/38.865875 is OK
- 10.21105/joss.03673 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

Wordcount for paper.md is 959

[editorialbot]

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

[jbytecode]

Dear @dmbates and @mkitti

This is the reviewing thread. First, please type

@editorialbot generate my checklist

to generate checklist. In this checklist there will be 20 check items for each reviewer. Whenever you complete the corresponding item, you can check them on. The reviewing process is interactive so you can always interact with the author(s) and the editor.

You can discuss issues here as well as in target the repository by opening new issues. If you open a new issue in the target repository, please mention them here so we can keep tracking what is going on outside the main thread.

Thank you in advance.

[jbytecode]

@baxmittens - at a first glance, it seems a citation for Julia is missing. could you please consider adding it?

@dmbates, @mkitti - could you please create your checklist by typing the editorialbot command given above?

Thank you all in advance.

[mkitti]

Review checklist for @mkitti

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/baxmittens/VTUFileHandler?
• 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 (@baxmittens) 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

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 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?

[dmbates]

Review checklist for @dmbates

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/baxmittens/VTUFileHandler?
• 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 (@baxmittens) 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

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 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?

[mkitti]

The authors introduce VTUFileHandler.jl, a Julia language package for handling VTK unstructured grid data. The package also provides a number of mathematical operators reminiscent of an algebraic field over addition and multiplication.

1. Currently VTUFileHandler.jl is not a registered Julia package. It depends on another unregistered package located at https://github.com/baxmittens/XMLParser, which is a bespoke "leightweight" [spelling error] package.

Does the author intend to register one or both packages?

Given the the XMLParser module is bespoke, is it really meant to be an independent package? Could it exist as a module within VTUFileHandler.jl?

2. Since part of the package deals with file based input and output, it would be useful if this functionality could be registered file handler via FileIO.jl

3. The registered package WriteVTK.jl appears to implement file loading and saving for .vtu files. A comparison to this package should be done. I would also appreciate if the author could explore interoperability with this package.

4. While the author asserts that this library "implements an algebra" I would like the author to defend this statement by addressing a few algebraic concepts.
   i) Are the operations associative?
   ii) Are the operations commutative?
   iii) Are there additive and multiplicative identities?
   iv) Are there additive and multiplicative inverses?
   v) Can multiplication be distributed over addition?
   vi) Over the set of VTUFiles do addition and multiplication form a mathematical field?
   v) Over the set of VTUFiles and Numbers do addition and multiplication form a multiplicative field?

5. The method nbytes is implemented as a utility within the package: https://github.com/baxmittens/VTUFileHandler.jl/blob/633c67c0d1f50c3d75903448b7800c8fa944d407/src/VTUFileHandler/vtuheader_utils.jl#L13-L17 . This appears to replicate the functionality of sizeof

julia> nbytes(UInt8)
1

julia> sizeof(UInt32)
4

julia> sizeof(UInt64)
8

julia> sizeof(Float64)
8

julia> sizeof(Int32)
4

julia> sizeof(Int64)
8

julia> sizeof(UInt8)
1

Could the definition const nbytes = sizeof replace the current hardcoded version?

To be continued...

[baxmittens]

@baxmittens - at a first glance, it seems a citation for Julia is missing. could you please consider adding it?

Gladly did so.

[jbytecode]

@editorialbot check references

[editorialbot]

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

OK DOIs

- 10.23919/EuCAP.2017.7928679 is OK
- 10.1109/38.865875 is OK
- 10.21105/joss.03673 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[jbytecode]

@editorialbot generate pdf

[editorialbot]

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

[baxmittens]

@mkitti - thank you for your comments. I would like to answer to them

1. Currently VTUFileHandler.jl is not a registered Julia package. It depends on another unregistered package located at https://github.com/baxmittens/XMLParser, which is a bespoke "leightweight" [spelling error] package.

Fixed the typo.

Does the author intend to register one or both packages?

Not at this point but maybe later. I elaborate on this below

Given the the XMLParser module is bespoke, is it really meant to be an independent package? Could it exist as a module within VTUFileHandler.jl?

I use it in other projects of mine too. For example for some simple html and OpenGeoSys input file manipulations. Thinking in term of functions, XMLParser.jl should be a stand-alone package since it has a distinctive function. I'm no big fan of mixing too many diffierent functionalities in one project since it complicates the expandability and the maintainbility.
What I would consider is replacing my XMLParser for a better one. The problem is, to my knowledge, there is no XMLParser available which is written purely in Julia. All projects I know (LightXML.jl , EzXML.jl) use libxml2 as a basis, which I wanted to avoid.

And finally, even VTUFileHandler.jl is only part of a bigger project. As I wrote earlier (in Prereview), I implemented an adaptive sparse-grid colloction method (see sparse grid theory paper) which uses the VTUFileHandler and a broader stochastic / hpc framework which uses the adaptive sparse-grid. I could throw this all in one package but I thought it would be much better to distribute this big project in smaller packages according to their functionalities. I plan on publishing two consecutive joss-papers describing the sparse-grid and the stochastic-hpc-framework

2. Since part of the package deals with file based input and output, it would be useful if this functionality could be registered file handler via FileIO.jl
3. The registered package WriteVTK.jl appears to implement file loading and saving for .vtu files. A comparison to this package should be done. I would also appreciate if the author could explore interoperability with this package.

Before starting this project, I looked into both WriteVTK.jl and ReadVTK.jl and at that point both package were not really a good fit for what I was planning on doing. But as things progress I would definetly consider rebasing my stuff onto their projects.
That is a reason why I don't think VTUFileHanlder.jl should be a registered julia package at the moment.

4. While the author asserts that this library "implements an algebra" I would like the author to defend this statement by addressing a few algebraic concepts.
   i) Are the operations associative?
   ii) Are the operations commutative?
   iii) Are there additive and multiplicative identities?
   iv) Are there additive and multiplicative inverses?
   v) Can multiplication be distributed over addition?
   vi) Over the set of VTUFiles do addition and multiplication form a mathematical field?
   v) Over the set of VTUFiles and Numbers do addition and multiplication form a multiplicative field?

As mentioned in the paper, if operators should be applied the objects have to share the same topology. If they do, all operators act point-wise on each corresponding pair of e.g. nodal coefficients. The operators itself keep their properties as they perform their action on a collection of scalars. Each nodal coefficient $\hat{u}\in\mathbb{R}$ is an independet entity.

5. The method nbytes is implemented as a utility within the package: https://github.com/baxmittens/VTUFileHandler.jl/blob/633c67c0d1f50c3d75903448b7800c8fa944d407/src/VTUFileHandler/vtuheader_utils.jl#L13-L17 . This appears to replicate the functionality of sizeof

Thank you. Changed all nbytes to sizeof. That makes a lot more sense...

Sorry for the long answer.

[jbytecode]

Looks like there are lots of "my needs" instead of "community's needs", the software can be refactored in lights of the reviews.

The dependency XMLParser as declared in the Project.toml is not a standard Julia package - I am sharing the same thoughts with the reviewer.

Altought it is not strictly needed, we always encourage authors to submit their packages so it fits well with the eco-system of the language and the environments.

At the end of the story, the software should solve a generalized problem with an easy and painless installation process.

[baxmittens]

Looks like there are lots of "my needs" instead of "community's needs", the software can be refactored in lights of the reviews.

The dependency XMLParser as declared in the Project.toml is not a standard Julia package - I am sharing the same thoughts with the reviewer.

Altought it is not strictly needed, we always encourage authors to submit their packages so it fits well with the eco-system of the language and the environments.

At the end of the story, the software should solve a generalized problem with an easy and painless installation process.

Agree, this was a project that originally was created only in my needs and I was asked to open-source it because other people wanted to use it. But I do think it solves a generalized problem quite handy.
And I also think the installation process is painless since no package has dependencies which is quite nice if you think about computations on heterogenous cluster architectures.

[mkitti]

Before starting this project, I looked into both WriteVTK.jl and ReadVTK.jl and at that point both package were not really a good fit for what I was planning on doing. But as things progress I would definetly consider rebasing my stuff onto their projects.
That is a reason why I don't think VTUFileHandler.jl should be a registered julia package at the moment.

Regarding package registration, I do not see how dependence on the other packages or lack there of would prevent package registration. This can always be modified in subsequent vesions of the package. VTUFileHandler.jl is either a reusable library or a terminal application.

1. A reusable library should be in a registry of some sort to facilitate installation.
2. Alternatively, a terminal application should have a Manifest.toml for reproducibility as well as a DOI via a service like Zenodo.

Per the review criteria on https://joss.readthedocs.io/en/latest/review_criteria.html#installation-instructions:

Where possible, software installation should be managed with a package manager. However, this criterion depends upon the maturity and availability of software packaging and distribution in the programming language being used. For example, Python packages should be pip installable, and have adopted packaging conventions.

Julia has a mature software packaging system and for publication VTUFileHandler.jl should take full advantage of it. I will let the author decide between the two options above, but one of them must be chosen as a requirement of publication. The choice will also affect how to integrate the XMLParser module.

See https://github.com/JuliaRegistries/General#should-i-register-my-package

[mkitti]

7. While the author asserts that this library "implements an algebra" I would like the author to defend this statement by addressing a few algebraic concepts.
i) Are the operations associative?
ii) Are the operations commutative?
iii) Are there additive and multiplicative identities?
iv) Are there additive and multiplicative inverses?
v) Can multiplication be distributed over addition?
vi) Over the set of VTUFiles do addition and multiplication form a mathematical field?
v) Over the set of VTUFiles and Numbers do addition and multiplication form a multiplicative field?

As mentioned in the paper, if operators should be applied the objects have to share the same topology. If they do, all operators act point-wise on each corresponding pair of e.g. nodal coefficients. The operators itself keep their properties as they perform their action on a collection of scalars. Each nodal coefficient $\hat{u}\in\mathbb{R}$ is an independet entity.

Thank you for this comment. Please clarify the above points in the paper, clearly delineating how this library implements an algebra such as a field. If you feel there is an alternative algebra, please state what it is. Specifically there are a couple missing parts I have identified so far:

1. Additive inverse with a unary - operator.
2. Multiplicative identity (e.g. Base.one).

[mkitti]

The problem is, to my knowledge, there is no XMLParser available which is written purely in Julia. All projects I know (LightXML.jl , EzXML.jl) use libxml2 as a basis, which I wanted to avoid.

It would be good to document this in the README for XMLParser.

[baxmittens]

Regarding package registration, I do not see how dependence on the other packages or lack there of would prevent package registration. This can always be modified in subsequent vesions of the package. VTUFileHandler.jl is either a reusable library or a terminal application.

1. A reusable library should be in a registry of some sort to facilitate installation.
2. Alternatively, a terminal application should have a Manifest.toml for reproducibility as well as a DOI via a service like Zenodo.

Per the review criteria on https://joss.readthedocs.io/en/latest/review_criteria.html#installation-instructions:

Where possible, software installation should be managed with a package manager. However, this criterion depends upon the maturity and availability of software packaging and distribution in the programming language being used. For example, Python packages should be pip installable, and have adopted packaging conventions.

Julia has a mature software packaging system and for publication VTUFileHandler.jl should take full advantage of it. I will let the author decide between the two options above, but one of them must be chosen as a requirement of publication. The choice will also affect how to integrate the XMLParser module.

See https://github.com/JuliaRegistries/General#should-i-register-my-package

Sorry but I disagree, here.
My package already meets the review criteria (Good: The software is simple to install, and follows established distribution and dependency management approaches for the language being used).

Via

import Pkg
Pkg.add(url="https://github.com/baxmittens/XMLParser.jl.git")
Pkg.add(url="https://github.com/baxmittens/VTUFileHandler.jl.git")

the package is registered in the julia package manager. it will be automatically updated if Pkg.update() is called and a new version is available. All dependencies are listed in the Project.toml.

A Manifest.toml is not needed here. You can think of the Manifest as a fixed snapshot of the Project.toml which is needed if your package requires specific versions/releases of its dependecies for a given application. In other words for specific applications it can be necessary that the user has the very same environment and thus a Manifest.toml has to be included.

This is not necessary here since my package should work with all versions of julia 1.x and only uses Julia.Base besides the XMLParser. I always thought that in that case you should avoid to add a Manifest.toml since this would result in overly restricting the versions of the package dependencies and leads to large .julia folders.

In some cases a test/Manifest.toml seems appropriate but in my case I don't see why. Only in case incompatibilites with other packages are occuring, I should add a Manifest.toml. Right?

I always thought this would be good julia practice. See for example timholy's projects.

Edit: While reading further into the topic, I don't know if the above is right. It seems like the Manifest.toml would be added automatically, if the I would register the Project in the Julia package manager. But still, adding a Manifest.toml manually to the repo doesn't make sense, right?

[baxmittens]

The problem is, to my knowledge, there is no XMLParser available which is written purely in Julia. All projects I know (LightXML.jl , EzXML.jl) use libxml2 as a basis, which I wanted to avoid.

It would be good to document this in the README for XMLParser.

Thank you for the suggestion. Added it in the readme.

[baxmittens]

7. While the author asserts that this library "implements an algebra" I would like the author to defend this statement by addressing a few algebraic concepts.
   i) Are the operations associative?
   ii) Are the operations commutative?
   iii) Are there additive and multiplicative identities?
   iv) Are there additive and multiplicative inverses?
   v) Can multiplication be distributed over addition?
   vi) Over the set of VTUFiles do addition and multiplication form a mathematical field?
   v) Over the set of VTUFiles and Numbers do addition and multiplication form a multiplicative field?

As mentioned in the paper, if operators should be applied the objects have to share the same topology. If they do, all operators act point-wise on each corresponding pair of e.g. nodal coefficients. The operators itself keep their properties as they perform their action on a collection of scalars. Each nodal coefficient $\hat{u}\in\mathbb{R}$ is an independet entity.

Thank you for this comment. Please clarify the above points in the paper, clearly delineating how this library implements an algebra such as a field. If you feel there is an alternative algebra, please state what it is. Specifically there are a couple missing parts I have identified so far:

Let V=(VTUFile,+,*) be a field and A \subseteq R^n a vector space over V. Then V is an algebra if for all x,y,z \in A and a,b \in V the following holds:

1. (x+y) * z = x * z + y * z
2. z * (x+y) = z * x + z * y
3. (ax) * (bx) = (ab)(x * y)

which surely applies but I don't really think this should be included in the paper or should it?

1. Additive inverse with a unary - operator.
2. Multiplicative identity (e.g. Base.one).

Added those, thank you.

[mkitti]

I don't really think this should be included in the paper or should it?

The language of the title is very specific. So yes, I think the contents of the a article should support the statement in the title.

[baxmittens]

@editorialbot generate pdf

[editorialbot]

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

[jbytecode]

• line 26 : julia -> Julia
• line 41 : remove the line =========

@baxmittens could you please fix those items in paper? please have a full read and correct other typos if exist.

[baxmittens]

@editorialbot generate pdf

[editorialbot]

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

[jbytecode]

@baxmittens - it seems okay now. Could you please continue with the following steps that I've mentioned above?

[baxmittens]

@jbytecode - I'm just about finishing...sorry for taking that long

[jbytecode]

@baxmittens - no worries, thank you.

[baxmittens]

• tagged release version id: v0.2.0
• zenodo archive DOI: 10.5281/zenodo.6576155
• zenodo archive url: https://doi.org/10.5281/zenodo.6576155

[jbytecode]

@editorialbot set v0.2.0 as version

[editorialbot]

Done! version is now v0.2.0

[jbytecode]

@editorialbot set 10.5281/zenodo.6576155 as archive

[editorialbot]

Done! Archive is now 10.5281/zenodo.6576155

[jbytecode]

@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.23919/EuCAP.2017.7928679 is OK
- 10.21105/joss.03673 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

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

Check final proof 👉 openjournals/joss-papers#3226

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

[jbytecode]

@baxmittens thank you for the submission, @mkitti and @dmbates thank you for your valuable reviews and consuming your time for JOSS.

One of the @openjournals/joss-eics will have the final decision.

Thank you!

[baxmittens]

@jbytecode @mkitti @dmbates - thank you for reviewing my first joss article.
Your help greatly improved the quality of my project and the paper as well. I really appriciate it!
I will publish further articels here, i guess. The next time I will be better prepared and setting up documentaion and stuff will only take me a fraction of the time I spent for this project. So I really feel I do benefit from undergoing this review procedure. Thanks again to you all, maybe we'll meet again some day : )

[arfon]

@editorialbot accept

[editorialbot]

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

[editorialbot]

🐦🐦🐦 👉 Tweet 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.04300 joss-papers#3235
1. Wait a couple of minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.04300
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]

@dmbates, @mkitti – many thanks for your reviews here and to @jbytecode for editing this submission! JOSS relies upon the volunteer effort of people like you and we simply wouldn't be able to do this without you ✨

@baxmittens – your paper is now accepted and published in JOSS ⚡🚀💥

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

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

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

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