[REVIEW]: FEM_2D: A Rust Package for 2D Finite Element Method Computations with Extensive Support for *hp*-refinement

[whedon]

Submitting author: @jeremiah-corrado (Jeremiah Corrado)
Repository: https://github.com/jeremiah-corrado/fem_2d
Branch with paper.md (empty if default branch):
Version: 0.2.2
Editor: @jedbrown
Reviewers: @jeremylt, @YohannDudouit
Archive: 10.5281/zenodo.7849878

⚠️ JOSS reduced service mode ⚠️

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/1f6d4416b383d6fe96b4008334ea1bef"><img src="https://joss.theoj.org/papers/1f6d4416b383d6fe96b4008334ea1bef/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/1f6d4416b383d6fe96b4008334ea1bef/status.svg)](https://joss.theoj.org/papers/1f6d4416b383d6fe96b4008334ea1bef)

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

@jeremylt & @YohannDudouit, 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 @jedbrown 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 ✨

[whedon]

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

⚠️ JOSS reduced service mode ⚠️

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.

⭐ 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]

Wordcount for paper.md is 1173

[whedon]

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

OK DOIs

- 10.36227/techrxiv.16695163.v1 is OK
- 10.36227/techrxiv.14807895.v1 is OK
- 10.1145/1089014.1089019 is OK
- 10.1007/978-1-4612-1986-6_8 is OK
- 10.1515/jnma-2021-0081 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

Software report (experimental):

github.com/AlDanial/cloc v 1.88  T=0.21 s (163.7 files/s, 56075.1 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Rust                            23            797            731           5675
JSON                             6              3              0           4281
Markdown                         3             93              0            266
TeX                              1              9              0             89
TOML                             1              2              0             23
YAML                             1              1              4             18
-------------------------------------------------------------------------------
SUM:                            35            905            735          10352
-------------------------------------------------------------------------------


Statistical information for the repository '4e5b9574b6f1c023162ffc94' was
gathered on 2022/02/16.
The following historical commit information, by author, was found:

Author                     Commits    Insertions      Deletions    % of changes
Jeremiah                         2          1664              0           24.67
jeremiah-corrado                10          1708           3372           75.33

Below are the number of rows from each author that have survived and are still
intact in the current revision:

Author                     Rows      Stability          Age       % in comments

[whedon]

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

[jedbrown]

Hi @jeremylt @YohannDudouit 👋 Welcome to JOSS and thanks for agreeing to review! The comments from @whedon above outline the review process, which takes place in this thread (possibly with issues filed in the FEM_2D repository). I'll be watching this thread if you have any questions.

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

We aim for reviews to be completed within a month or so. Please let me know if you require some more time. We can also use Whedon (our bot) to set automatic reminders if you know you'll be away for a known period of time.

Please feel free to ping me (@jedbrown) if you have any questions/concerns.

[jeremylt]

@jedbrown, could you resend the invite? I waited too long before clicking the link.

[jedbrown]

Whedon retired young so we now ask @editorialbot generate my checklist. You don't need an invite.

[jeremylt]

Review checklist for @jeremylt

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/jeremiah-corrado/fem_2d?
• 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 (@jeremiah-corrado) 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?

[YohannDudouit]

Review checklist for @YohannDudouit

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/jeremiah-corrado/fem_2d?
• 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 (@jeremiah-corrado) 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?

[YohannDudouit]

I opened the issue jeremiah-corrado/fem_2d#2 containing a number of observations and suggestions.

[jeremylt]

Since @YohannDudouit made a pretty comprehensive review on the overall structure and I agree with many of his points, I focused on creating a few issues highlighting some more Rust specific technical aspects:

• Error Handling
• Struct Member Access
• Doc Comment Code Examples
• CI Tests

[jeremiah-corrado]

Thank you both for the detailed feedback! It's really nice to get an outside perspective on the design and documentation.

I am currently in prep-mode for my thesis defense, but I should be able to start addressing these issues within a couple of weeks.

In the meantime, I have a few questions and notes about the suggestions you made:

@YohannDudouit:

• I agree that much of the conceptual partitioning could use some slight adjustment, as well as better naming and documentation; however, I think a few of the structures should stay where they are. For example, M2D and V2D should be in the space module as part of the broader mesh module because they describe points and transformations in the 2D physical/parametric spaces where elements are defined. These are specialized data structures that do not have any utility to the linear algebra portion of the crate. Would it make more sense to rename the linalg module to something like "linear-solvers" to avoid this confusion?
• The ShapeFn trait is somewhat specialized to the work I've been doing with the Maxwell Eigenvalue problem. I like your idea about building up a hierarchy of traits to support a wider and more abstract range of shape function types! I'll look into this a bit further.
• MaxOrthoBasisFn also implements the ShapeFn trait, but it has to be included with the Nightly compiler using a feature-flag. I'll include more documentation about this.
• There is a Mass< u, v > operator
• Generally, I am not sure where to draw the line between implementing more functionality myself, and inviting open-source contribution for some of these features, such as extended ShapeFns, Integrals, and a linear-solver. Do you think it would be appropriate to leave some of these things as open issues for people to work on? Or should they be part of the library right away?

@jeremylt:

• I was not aware of Tarpaulin, so I'll give that a try.
• I also did not know about the #![doc = include_str!("../README.md")] flag. I'll include that to take care of crate-level testing and then move towards more code-sample based testing (in addition to the module-level tests).
• As far as I know, the public struct members are all intended to be public. I'll provide some more concise documentation or examples of how those could be used.
• All of the internal calls to .unwrap() are made when I know that a function call will not return an Err. For example, in the global_h_refinement() method on Mesh, I call unwrap() on elem_is_h_refineable() because it only returns an Err when the provided elem_id does not exist. In this case I know that it does exist because I am iterating over the list of elems. Therefore, I can call unwrap rather than propagating the error using the "?" operator. Would it be helpful if I make a case for the validity of calling unwrap in the documentation for these methods?
• I'll update the paper example (and readme example) to return a Result<()> from main and use ? instead of unwrap(). I agree that this is more idiomatic, I was just trying to avoid the often confusing Ok(()) at the bottom of the function.
• Otherwise, did you have additional concerns about error handling? If so, would you be able to provide a specific example of the non-uniformity you are referring to?

Thanks again for all the excellent feedback!

[jedbrown]

I'll just respond to the question about scope. There is a limitless number of extensions and improvements for any nontrivial software so you have to draw the line somewhere. I think you want to try hard to make the architecture ready to receive contributions. If the new thing looks like implementing a trait or adding an enum variant, it's tractable to many more people than if it requires refactoring deeper assumptions. Such modularity can easily go overboard as well, but if you think about desired extensions and put yourself in the shoes of someone who might be interested in implementing, you should be able to identify what is "ready" and what is "theoretically, one could refactor the code to add".

[jeremylt]

• All of the internal calls to .unwrap() are made when I know that a function call will not return an Err. For example, in the global_h_refinement() method on Mesh, I call unwrap() on elem_is_h_refineable() because it only returns an Err when the provided elem_id does not exist. In this case I know that it does exist because I am iterating over the list of elems. Therefore, I can call unwrap rather than propagating the error using the "?" operator. Would it be helpful if I make a case for the validity of calling unwrap in the documentation for these methods?

That all makes sense for your codebase at this moment in time - at the very least I'd recommend you document for your future self why those unwraps are valid. I still wouldn't do this though, personally. You are tightly coupling these pieces of code with implicit assumptions - specifically you are assuming that there is only one way for this function call to fail and that the constructor and/or specific usage for this object prevents this one failure mode. You are now responsible for maintaining these (undocumented!) assumptions through any changes to the function or the object. Why not just let the error handler keep track of this for you and let it give you a nice error message if future design decisions push you into an error case you hadn't originally anticipated? Unless you identify specific performance bottlenecks, I personally find it easier for future development to make use of the ergonomic language features and let the compiler optimize out the parts you don't need. I tend to assume that the error handling is free/nearly free until I profile that it is a bottleneck. Maybe I'm just a bit paranoid/defensive in my coding, but I tend to make everything but the simplest getters or helper functions return a Result.

Ultimately your call on what conventions you adopt here. I think it saves a ton of future headache to just use Results and ? everywhere, but I think you should at least note why these unwraps shouldn't ever fail in case future development changes those assumptions.

[jeremiah-corrado]

Hello all,

Just a quick update to summarize some recent progress:

• I made significant changes to the library over the last couple weeks to address @YohannDudouit's and @jeremylt's concerns/suggestions.
• @YohannDudouit, I left a detailed response to your issue. I believe I addressed most of your concerns. For those that I did not, I either left a question or some reasoning for maintaining the initial design. I welcome any further feedback (or rebuttals to my rebuttals)
• @jeremylt and I are making progress towards resolving his issues. Again, I welcome any further feedback on the points that have not been resolved yet
• The paper has been updated to reflect the design changes in the library
• I also published a new version of the library to crates.io, so this documentation is up to date (minus some very small changes in the last few commits).

Thanks for all the feedback and discussion so far!

[jedbrown]

That's great to hear. Thanks for the status update.

[jedbrown]

@editorialbot generate pdf

[editorialbot]

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

[jeremylt]

My issues have been addressed.

One minor point - I suspect 'galerking sampling' on page 6, footnote 1 should be 'Galerkin Sampling'

[jedbrown]

@YohannDudouit Could you give us an update as to whether your questions have been sufficiently addressed and the remaining items on your checklist?

[YohannDudouit]

@jedbrown We may want to discuss specific points to see if they meet the JOSS criteria, in particular "Substantial scholarly effort", "Functionality", "Performance", "Functionality documentation", "A statement of need", and "State of the field".

If I find this work overall interesting, I have some concerns though. The purpose of this library and the targeted audience is not very clear to me. The paper introduction claims "benefits" of the RBS approach without clearly stating what these are. The "Statement of need" opens with "Efficiently computing FEM solutions" and mentions the library Deal.II as a point of comparison, however it would be good to clarify what "efficient" means in this context and what are the aspects of Deal.II on which to compare (performance?). The main advantage over Deal.II seems to be "The succinctness of the continuity enforcement algorithm removes much of the difficulty of implementing new features. This is a major barrier to entry for contributing to larger and more complex packages."; I don't know Deal.II very well, but it seems suspicious to me that implementing new features usually requires a good understanding of continuity enforcement algorithms, for instance, in the MFEM library users very rarely have to be aware of these algorithms to implement new features. After investigating the implementation I also have strong doubts about the performance and therefore the capacity to "Efficiently comput[e] FEM solutions". I also find the documentation minimalist, the documentation of traits, struct, and functions rarely exceed a few lines. The main page is also outdated, the ShapeFn and Integral traits do not exist any more, and give an erroneous impression of generality of the library. I also find multiple names particularly confusing for users:

• traits with Fn in their name don't behave like functions (for instance, HierCurlBasisFn is closer to a container than a function),
• Elem and Element to name reference element and physical elements make it hard to know which is which,
• the library redefines what a degree of freedom is regardless of the mathematical definition: "I am defining a Degree-of-Freedom as a set of one or more BasisSpecs. A BasisSpec gives an abstract definition for a Basis Function over an individual Elem. Specifically, it defines the expansion-orders, direction, and classification (Element-Type, Edge-Type, Node-Type). Element-Type basis functions constitute degrees of freedom on their own, as they are zero-valued along the relevant edges. Pairs of Edge-Type functions constitute degrees of freedom, as they are non-zero on one relevant edge, and must share a scalar value to enforce continuity. Sets of four Node-Type functions make up degrees of freedom for the same reason. As such, a DoF describes a unit of the global solution which can take a scalar value."

This brings me to some of the issues I have been trying to bring attention here. One of the main advantages of the Rust language is to allow zero-cost high-level abstraction, therefore having interfaces close to the mathematical concepts while hiding implementation details. I think the fem_2D library does not do a good job at separating abstraction and implementation, specifically implementation details often pollutes the abstraction in my opinion, resulting in interfaces that mix user interfaces and implementation details. I found it difficult while exploring the library to identify what was meant to be user interface and what was more internal. In particular, it seems to me that the claim that the library can easily be extended to support all sorts of finite elements is exaggerated in the current state. Currently, only H(curl) is supported, and specificities about such finite elements pollutes the generality of the finite element abstractions, and mostly discourage external contributions due to large refactors that extending the library would require (even for simpler finite elements such as H1), see this example. Finally, I find it hard to answer the question: "Why would I choose to contribute to fem_2d rather than another open-source finite element library?".

[jedbrown]

Thanks @YohannDudouit for your comprehensive review.

@jeremiah-corrado how are you doing? From the perspective of JOSS, we are looking for accuracy. So if you don't want to make major changes to the library, you can adjust the abstract to make clear that it's a library for linear $H(\text{curl})$ problems or whatever is an accurate statement of what is currently supported. Of course software can hypothetically be extended to do lots of things, but if there isn't an interface with more than one implementation showing how it works, it's unlikely to attract developers to actually do that work (and exaggerated claims are likely to turn off people who might otherwise be capable of doing such work). So please just let us know what you plan to do and don't hesitate to ask questions.

As an aside, I notice that the quadrature interface handles only weights, leaving the points to the user to index manually. This Fn(usize, usize) -> f64 is an unusual interface in mathematical software; usually the quadrature routine would be aware of the points and thus the integrand would be Fn(f64, f64) -> f64, which is easier to use and performs just as well.

[jedbrown]

Hi @jeremiah-corrado 👋. I just wanted to check in about your plans. To be clear, you don't need to make major changes to the code in order to publish in JOSS, but the paper and docs need to accurately state what the software is now, not what you imagine it can become. Of course you're welcome to act on the review in the form of major code changes.

[danielskatz]

@jeremiah-corrado - I'm checking on the warning above and proofreading your paper, and will let you know next steps soon

[danielskatz]

@jeremiah-corrado - I've suggested some changes for language and to fix the warnings in jeremiah-corrado/fem_2d#12. You also might want to define/explain h and p in the fourth paragraph of the paper (or before that).

[danielskatz]

@jedbrown - As a note, this paper now seems far too long for a JOSS paper, and I think that a lot of it probably should be in the documentation, but its not worth changing at this point. I don't think it was so long when it was first submitted, so I assume additions were made during the review process. If I'm wrong and it started out this long, sorry. But if I'm right, please consider this in future reviews, where some of the details in the paper be in the documentation instead.

[danielskatz]

@editorialbot check repository

[editorialbot]

Software report:

github.com/AlDanial/cloc v 1.88  T=0.04 s (955.7 files/s, 249364.5 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Rust                            25            828           1663           5874
Markdown                         3            132              0            374
TeX                              1             10              0            107
JSON                             3              3              0             71
YAML                             2              6              4             35
TOML                             1              2              0             23
-------------------------------------------------------------------------------
SUM:                            35            981           1667           6484
-------------------------------------------------------------------------------


gitinspector failed to run statistical information for the repository

[editorialbot]

Wordcount for paper.md is 3201

[jeremiah-corrado]

Thanks @danielskatz, I merged your PR and added a brief description of h- and p-refinement to paragraph four.

[danielskatz]

@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.36227/techrxiv.19636770.v1 is OK
- 10.36227/techrxiv.16695163.v1 is OK
- 10.36227/techrxiv.14807895.v1 is OK
- 10.1145/1089014.1089019 is OK
- 10.1007/978-1-4612-1986-6_8 is OK
- 10.1515/jnma-2021-0081 is OK
- 10.1016/j.camwa.2020.06.009 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

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

Check final proof 👉📄 Download article

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

[danielskatz]

@editorialbot accept

[editorialbot]

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

[editorialbot]

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

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

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

CITATION.cff

cff-version: "1.2.0"
authors:
- family-names: Corrado
  given-names: Jeremiah
  orcid: "https://orcid.org/0000-0003-2688-0600"
- family-names: Harmon
  given-names: Jake J.
- family-names: Ilic
  given-names: Milan M.
- family-names: Notaroš
  given-names: Branislav M.
doi: 10.5281/zenodo.7849878
message: If you use this software, please cite our article in the
  Journal of Open Source Software.
preferred-citation:
  authors:
  - family-names: Corrado
    given-names: Jeremiah
    orcid: "https://orcid.org/0000-0003-2688-0600"
  - family-names: Harmon
    given-names: Jake J.
  - family-names: Ilic
    given-names: Milan M.
  - family-names: Notaroš
    given-names: Branislav M.
  date-published: 2023-04-21
  doi: 10.21105/joss.04172
  issn: 2475-9066
  issue: 84
  journal: Journal of Open Source Software
  publisher:
    name: Open Journals
  start: 4172
  title: "FEM_2D: A Rust Package for 2D Finite Element Method
    Computations with Extensive Support for hp-refinement"
  type: article
  url: "https://joss.theoj.org/papers/10.21105/joss.04172"
  volume: 8
title: "FEM_2D: A Rust Package for 2D Finite Element Method Computations
  with Extensive Support for *hp*-refinement"

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

Find more information on .cff files here and here.

[editorialbot]

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

[editorialbot]

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

[editorialbot]

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

Here's what you must now do:

0. Check final PDF and Crossref metadata that was deposited 👉 Creating pull request for 10.21105.joss.04172 joss-papers#4164
1. Wait a couple of minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.04172
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...

[danielskatz]

Congratulations to @jeremiah-corrado (Jeremiah Corrado) and co-authors on your publication!!

And thanks to @jeremylt and @YohannDudouit for reviewing, and to @jedbrown for editing!
We couldn't do this without your voluntary effort

(I see that the DOI isn't yet resolving, so I'll keep this issue open until it does, which hopefully should be in the next few hours at the latest)

[danielskatz]

The DOI is now resolving!

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

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

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

This is how it will look in your documentation:

We need your help!

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

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