@kyleniemeyer I noticed two small mistakes while proof reading the paper just now.

1. The DOI of the referenced report of Hickling & Plesset (1963) was incorrect (pointed to a different publication of the same authors.
2. The y-axis of Fig. 1(f) was incorrectly labelled as $\Delta p(r,t)$, whereas it should be labelled as $\Delta p(t)$, see caption.

I corrected both.

from joss-reviews.

@fabiandenner Oh I didn't read the README.md in the examples folder. Maybe point to these files more explicitly from the repository README.md.

from joss-reviews.

@svchb and @jmansour Just to let you know, I found a small mistake in the paper draft. The label of the $y$-axis in Figure 1(h) was incorrect, $u(r,t)$ instead of $u(r)$. I committed a corrected a figure.

from joss-reviews.

I've updated the examples and documentation as suggested by @svchb. The in-code documentation of the source files has been improved and every example now comes with a Python script to plot the results, including reference results from the literature where applicable, which also allows a quick validation of the installation. In addition, the example folder now also contains a shell script, run_all.sh, which compiles, runs and plots the results of all examples. I updated the README.md and the pdf-documentation accordingly. Sample results can now also be found in the pdf-documentation.

from joss-reviews.

Thanks for the nice work!

from joss-reviews.

Hi @kyleniemeyer

Yep, I'll have it done within a week.

from joss-reviews.

@jmansour Thank you very much for the detailed review and the excellent suggestions. No need to apologize for your review "coming in at the taller end of the review time window" - I prefer a constructive and diligent review over a rushed response. I'm glad to hear that you have had a good time exploring our software library.

Your suggestions are very much appreciated. I have just committed a small update including a Requirements section in the main README.md and in the pdf documentation (see Section 2.1). As we have been using this library actively for our research, we have taken the utmost care in implementing the various model correctly and given the breadth of previously published results APECSS reproduces accurately, we are confident that we have succeeded in that quest. Nevertheless, the automated quantitative tests you suggested are a very good idea. I'll try to find some time in the coming days to explore how we can best incorporate such quantitative tests, for instance, as you suggested, using numpy.allclose() in the run_all.sh script.

Regarding your further thoughts, we have already been thinking about introducing bindings for Python and Fortran, but haven't had the opportunity to pursue this further. I absolutely agree with you that this would increase the accessibility significantly. We considered CMake for convenience and especially during the development this simplifies things. However, we will keep adding alternatives to CMake (i.e. providing simple, ready to go Makefiles) in mind as a future addition. Automated tests are already in development, as mentioned above. Regarding the shebangs, thanks for pointing this out to us. We've simply forgotten to add them because the scripts run with both bash and zsh shells. We'll add them shortly.

Thanks again for the helpful suggestions!

from joss-reviews.

@jmansour I have just committed a results check to one of the examples (Rayleigh collapse with emissions) using numpy.allclose() in the corresponding Python script for plotting. This test is included in the run_all.sh script as well as the Github Action Build test executed for every commit and every pull request. Both script and GitHub runner exit with an error if the results don't match. Nice addition, thanks again for the suggestion!

The reason for picking this particular test case is that it includes acoustic emissions (i.e. makes use of all key features of APECSS) but the time step is constant. This test case has also been validated successfully using full Navier-Stokes results produced by a state-of-the-art CFD solver (see Figs. 2 and 3 in https://doi.org/10.1063/5.0131930), which I think further improves the confidence in the results.

For examples with varying time-step (adapted based on the solution error) I found there's a high chance that the number of time-steps and/or sub-iterations are not exactly the same when run on different machines/systems (Linux vs. MacOS, Intel vs. AMD vs. AppleSilicon). Consequently, the output arrays of reference and computed results do not have the same length, which makes numpy.allclose() exit with an error. I noticed this first with the Github Action runner (Apple worked, Linux failed), but I experienced the same on different machines in my lab here. Finding a more universally applicable solution for testing, e.g. comparing spline fits on the results and/or comparing the frequency spectra of the emissions, is duly noted for future exploration.

The documentation and main README.md have been updated accordingly. Also, I added bash shebangs to all shell scripts.

Is there anything else you want me to add or change?

from joss-reviews.

Nice work @fabiandenner! Sometimes it can indeed be challenging to ensure tests remain robust across a number of platforms. The options you mention are a good idea, although sometimes simply increasing the error tolerance is also fine (if perhaps less satisfying). Also, I came across the following paper at some point which provides an analytic solution for RP governed bubble growth. Maybe worth a look, as an analytic solution would be an excellent addition to your library's validation portfolio:
https://amsemodelling.com/publications/advances_in_modelling/General_Mathematics/552/55.02_07.pdf

That covers everything from my end. Happy for the publication to proceed. @kyleniemeyer

Best with the project @fabiandenner.

from joss-reviews.

@svchb and @jmansour
Thank you both, also on behalf of my co-author @SoerenSchenke, for the helpful review and the constructive suggestions. This was certainly a worthwhile experience since, aside from improving the quality of the software project, we also learned about how to make open-source projects more accessible.

@jmansour Thanks for the suggestion of the analytical solution, we will have a look into it. Comparing against an analytic solution was the main motivation for the Rayleigh collapse simple example. (i) All dissipation mechanisms are neglected, meaning the bubble should oscillate with constant amplitude, and (ii) the collapse time may be compared with the analytical collapse time proposed by Rayleigh. APECSS reproduces both accurately.

from joss-reviews.

Thanks so much for your helpful feedback @jmansour!

from joss-reviews.

@editorialbot accept

from joss-reviews.

🚨🚨🚨 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 👉 openjournals/joss-papers#4316
1. Wait a couple of minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.05435
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...

from joss-reviews.

@kyleniemeyer Thanks for wrapping this up and thanks to @svchb and @jmansour for taking the time to review our paper and code.

I hope other journals take notice of the excellent workflow JOSS is running, very good work!

from joss-reviews.

Congratulations @fabiandenner on your article's publication in JOSS! If you haven't already, please sign up as a reviewer so you can help us with submissions in the future: https://reviewers.joss.theoj.org/join

Many thanks to @jmansour and @svchb for reviewing this.

from joss-reviews.

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

from joss-reviews.

Software report:

github.com/AlDanial/cloc v 1.88  T=0.04 s (1181.0 files/s, 251896.7 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               15            928            639           4151
TeX                             11            381            242           3195
C/C++ Header                     1             98             91            488
YAML                             4             22              5            268
Markdown                         9             79              0            234
CMake                            6             48              0            198
Bourne Shell                     6              0              0             24
-------------------------------------------------------------------------------
SUM:                            52           1556            977           8558
-------------------------------------------------------------------------------


gitinspector failed to run statistical information for the repository

from joss-reviews.

Wordcount for paper.md is 1637

from joss-reviews.

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

OK DOIs

- 10.1146/annurev.fl.09.010177.001045 is OK
- 10.1088/0034-4885/73/10/106501 is OK
- 10.1146/annurev.fl.19.010187.000531 is OK
- 10.1016/j.ultsonch.2022.106131 is OK
- 10.1016/j.ultsonch.2020.105441 is OK
- 10.1016/j.jmatprotec.2022.117586 is OK
- 10.1016/j.ultsonch.2016.12.012 is OK
- 10.1021/acs.chemrev.1c00622 is OK
- 10.1007/978-94-017-7255-6 is OK
- 10.1016/j.ultrasmedbio.2020.01.002 is OK
- 10.1103/RevModPhys.74.425 is OK
- 10.1017/jfm.2022.202 is OK
- 10.1021/acs.chemrev.1c00438 is OK
- 10.1073/pnas.1019623108 is OK
- 10.1557/mrs.2019.107 is OK
- 10.1038/s41598-017-14312-0 is OK
- 10.1098/rsif.2015.0930 is OK
- 10.1016/j.chaos.2008.04.011 is OK
- 10.1063/5.0131930 is OK
- 10.1098/rsfs.2011.0026 is OK
- 10.1148/radiol.11111417 is OK
- 10.1063/5.0043822 is OK
- 10.1109/JOE.2018.2853199 is OK
- 10.1073/pnas.1606915113 is OK
- 10.1039/C2LC20861J is OK
- 10.1080/14786440808635681 is OK
- 10.1115/1.4009975 is OK
- 10.1121/1.384720 is OK
- 10.1016/j.ultsonch.2020.105307 is OK
- 10.1121/1.2118307 is OK
- 10.1063/1.4817673 is OK
- 10.1016/j.ultras.2005.03.010 is OK
- 10.1121/1.2109427 is OK
- 10.1016/j.ultrasmedbio.2021.06.012 is OK
- 10.1016/0771-050X(80)90013-3 is OK
- 10.1063/1.4945981 is OK
- 10.1063/1.1701962 is OK
- 10.1098/rspa.2009.0594 is OK

MISSING DOIs

- 10.5962/bhl.title.48411 may be a valid DOI for title: Underwater Explosions
- 10.21236/ad0403347 may be a valid DOI for title: The Collapse of a Spherical Cavity in a Compressible Liquid

INVALID DOIs

- None

from joss-reviews.

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

from joss-reviews.

👋 Hi @fabiandenner @jmansour @svchb this is where the actual review takes place. Thanks!

from joss-reviews.

Thanks @kyleniemeyer.

Thanks @jmansour and @svchb for accepting the invitation to review our work. Please don't hesitate to let me know if you have any questions or suggestions.

from joss-reviews.

Review checklist for @svchb

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/polycfd/apecss?
• 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 (@fabiandenner) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
• Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

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

Documentation

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

Software paper

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

from joss-reviews.

@fabiandenner Your paper is lacking a section in which you compare APECSS to other software tools that can be used for bubble dynamics. I must add personally I am not aware of other software packages in this area.

from joss-reviews.

@kyleniemeyer It seems like @jmansour is not participating.

from joss-reviews.

Hi all. Apologies, this completely fell off the radar and I failed to notice the Github notifications until now.
I'll spend some time on this over the next few days and report back.

from joss-reviews.

@svchb I agree, a direct comparison of APECSS to similar software tools would be a nice addition. On multiple occasions, also just before submitting to JOSS as we anticipated this question, we tried our best to identify open-source tools with similar capabilities. However, we also couldn't find any. We validated APECSS thoroughly, especially in our Physics of Fluids paper published earlier this year, and this can also be checked with the examples provided in the repository (we mention the literature case it should reproduce in the README.md accompanying each example). In terms of performance, we could conduct a comparison to an in-house Python implementation, using SciPy functions (with the same Runge-Kutta method) to solve the governing ODE, for a few examples. I'm not sure how representative such an implementation would be, but it could at least give a rough orientation about the performance benefit. What do you think?

from joss-reviews.

@fabiandenner I had not yet time to check your code or examples. Anyway I am not sure how representative that would be as performance of Python based solvers largely depends on avoiding native Python code execution of computational intensive parts.

from joss-reviews.

@svchb I agree, our Python scripts are perhaps best described as a simple implementation with off-the-shelf components, not a sophisticated or performance-optimized implementation.

from joss-reviews.

@fabiandenner Please add how to run an example to your Readme.md.
Also nice would be to introduce an error message which points to the actual usage i.e. ./example-bin -options run.apecss and adding common command line help arguments i.e. -h/-help.
Also are the examples supposed to perform timesteps?

from joss-reviews.

@svchb Yes it is supposed to perform time steps. The README.md of this test case provides an example of the execution command (that corresponds to reproducing the references literature result). I think what's missing in your execution are the excitation frequency and amplitude, and the end time of the simulation.

I'll expand the Quick Start section of the main README.md file to include the additional steps to running one of the examples.

The help arguments is a nice idea, thanks for this suggestion. I'll add this. Also, I'll have a look into the error messages.

from joss-reviews.

@svchb I just committed some small changes. I expanded the Quick Start Guide in the primary README.md and moved it further up in the text, so that it is better visible. Also, -h now provides some basic command line help.

from joss-reviews.

Review checklist for @jmansour

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/polycfd/apecss?
• 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 (@fabiandenner) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
• Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

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

Documentation

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

Software paper

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

from joss-reviews.

@editorialbot generate pdf

from joss-reviews.

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

from joss-reviews.

Some comments:

• Your in-code documentation is lacking it would be better to document major functions within the code
• It would be nice if you add scripts to plot the output of your examples
• Your documentation file would benefit from more diagrams/illustrations/plots

Tests:

• Your tests only verify that the code compiles and runs. Please adjust the tests in a way that they compare to a verified result as well.

Besides this testing aspect I am satisfied with the paper, documentation and code.

from joss-reviews.

@svchb Thanks for the feedback. Following your suggestions I'll add:

• in-code documentation for major functions and source files.
• scripts to plot the results, together with reference results where applicable. Many of the examples reproduce results found in the literature (indicated in the corresponding README files), which can be used to validate the results. However, I agree with you, this might be a little cumbersome at the moment.
• sample results (produced with the scripts mentioned before) and illustrations to the pdf-documentation.

I'll try to find the time to add this by the end of the week.

Thank you very much for having taken the time to review our software and for the helpful feedback, we greatly appreciate it.

from joss-reviews.

@kyleniemeyer I have concluded my review and I am fine with the publication.

from joss-reviews.

Thank you @svchb!

from joss-reviews.

@jmansour just checking in on your review; do you think you'll be able to complete this soon? Thanks for your efforts!

from joss-reviews.

Hi all

Apologies for my response coming in at the taller end of the review time window. I was hoping to get it done sooner, but alas.

Firstly I'd like to commend the authors on this excellent contribution to scientific OSS canon. The library looks well written, using modern C paradigms and modularity, and this should bode well for the project's sustainability and future growth. The implemented functionality appears to be appropriately expressed via the API, and this is reflected in the provided examples which are clean, concise and easy to digest.

The library is extremely lightweight with minimal dependencies. This is a very advantageous for both end users and also third parties wanting to use your library to add cavitation dynamics to existing applications. Following the provided instructions, I found it trivial to build the library on Ubuntu and OSX. While the front Github page does state the dependencies within the text, I would like to see an explicit list provided under a "Requirements" section, and you should also list the optional requirements for plotting results (Python/numpy/matplotlib).
polycfd/apecss#14

The library appears to fill an important gap in scientific OSS. As discussed earlier in this thread, there doesn't appear to be any alternative open source offerings which explicitly model bubble dynamics and cavitation, which is indeed surprising given the maturity of the governing dynamics and breadth of application (as outlined within the author's JOSS submission). Fluent does appear to provide some cavitation functionality, but given it's a commercial package I don't think it needs to be considered here as an alternative.

Most of the examples provided within the repository reproduce results available in the literature:

• examples/binaryinteraction - Jiang et al 2017 (qualitative)
• examples/gastemperature - Stricker et al 2011 (qualitative)
• examples/laserinducedcavitation - Liang et 2022 (provided data)
• examples/rayleighcollapse - Denner & Schenke 2023 (provided data)
• examples/ultrasound_lipidcoated_simple - Marmottant et al 2005 (qualitative)
• examples/ultrasound_sonolum - Holzfuss 2010 (provided data)
• examples/ultrasound_kelvinvoigt - Yang & Church 2005 (qualitative)
• examples/ultrasound_zener - Zilonova et al 2018 (qualitative)
• examples/ultrasound_oldroydb - Jimenez-Fernandez & Crespo 2005 (qualitative)

I was able to reproduce all the above results locally, and I am satisfied that this is a sufficient demonstration of the correctness of the implementation. Note that I have trusted that the third party reference data provided within the repository is accurate.

The JOSS submission includes the results produced by the ultrasound_sonolum example, and this was able to be reproduced, although I also note that these are not original results so reproduction is perhaps not strictly required here.

I was able to use the run_all.sh script to automatically run all the provided examples, although as far as I can tell these do not perform any quantitative tests. I would like to see a simple quantitative test added as this is necessary for the verification of the software's functionality.
polycfd/apecss#15

With regards to the JOSS software paper itself, I am satisfied that it meets all the listed requirements.

from joss-reviews.

Some further thoughts/suggestions I have which you might consider for future work, although shouldn't block the JOSS acceptance:

• Generating Python bindings for your API would hugely increase accessibility for a large section of the modelling community, and generally wouldn't incur any appreciable performance overhead. I think this would be a relatively straightforward undertaking via tools such as Cython or SWIG given your library's design and minimal requirements.
• Consider dropping CMake, as it's a relatively heavy build system and overkill for your use case. Make would be entirely sufficient, and is generally available as default, but you could even have your compile scripts execute the required compilation sequence directly.
• Confidence could certainly be improved by providing datasets for the models where only qualitative comparison is currently possible. Automated tests for those too! 🙂
• You might considering using an automated API documentation tool such as Doxygen, as manually ensuring your documentation stays in sync with your code-base is difficult and error prone.
• I generally prefer C-libraries to by default generate debug builds, as this is generally what you will require during model construction, with release/optimised builds used for production runs. Though I note that you have provided instructions for debug builds within your documentation.
• You should add shebangs to your scripts to ensure they are executed by the appropriate interpreter.

from joss-reviews.

@editorialbot generate pdf

from joss-reviews.

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

from joss-reviews.

Post-Review Checklist for Editor and Authors

Additional Author Tasks After Review is Complete

• Double check authors and affiliations (including ORCIDs)
• Make a release of the software with the latest changes from the review and post the version number here. This is the version that will be used in the JOSS paper.
• Archive the release on Zenodo/figshare/etc and post the DOI here.
• Make sure that the title and author list (including ORCIDs) in the archive match those in the JOSS paper.
• Make sure that the license listed for the archive is the same as the software license.

Editor Tasks Prior to Acceptance

• Read the text of the paper and offer comments/corrections (as either a list or a PR)
• Check the references in the paper for corrections (e.g. capitalization)
• Check that the archive title, author list, version tag, and the license are correct
• Set archive DOI with @editorialbot set <DOI here> as archive
• Set version with @editorialbot set <version here> as version
• Double check rendering of paper with @editorialbot generate pdf
• Specifically check the references with @editorialbot check references and ask author(s) to update as needed
• Recommend acceptance with @editorialbot recommend-accept

from joss-reviews.

@fabiandenner we're now ready to wrap things up - can you please go through the above checklist of author tasks?

from joss-reviews.

@kyleniemeyer Sure, I'm on it.

from joss-reviews.

@editorialbot generate pdf

from joss-reviews.

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

from joss-reviews.

@kyleniemeyer I made a new release with the latest changes (v1.4) and archived it on Zenodo: https://doi.org/10.5281/zenodo.8043400

from joss-reviews.

@kyleniemeyer However, I can't seem to tick off the check list above. Did you give me permission to edit or am I doing something wrong?

from joss-reviews.

@fabiandenner no worries, I can check them off

from joss-reviews.

@editorialbot set 10.5281/zenodo.8043400 as archive

from joss-reviews.

Done! archive is now 10.5281/zenodo.8043400

from joss-reviews.

@editorialbot set v1.4 as version

from joss-reviews.

Done! version is now v1.4

from joss-reviews.

@editorialbot check references

from joss-reviews.

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

OK DOIs

- 10.1146/annurev.fl.09.010177.001045 is OK
- 10.1088/0034-4885/73/10/106501 is OK
- 10.1146/annurev.fl.19.010187.000531 is OK
- 10.1016/j.ultsonch.2022.106131 is OK
- 10.1016/j.ultsonch.2020.105441 is OK
- 10.1016/j.jmatprotec.2022.117586 is OK
- 10.1016/j.ultsonch.2016.12.012 is OK
- 10.1021/acs.chemrev.1c00622 is OK
- 10.1007/978-94-017-7255-6 is OK
- 10.1016/j.ultrasmedbio.2020.01.002 is OK
- 10.1103/RevModPhys.74.425 is OK
- 10.1017/jfm.2022.202 is OK
- 10.1021/acs.chemrev.1c00438 is OK
- 10.1073/pnas.1019623108 is OK
- 10.1557/mrs.2019.107 is OK
- 10.1038/s41598-017-14312-0 is OK
- 10.1098/rsif.2015.0930 is OK
- 10.1016/j.chaos.2008.04.011 is OK
- 10.1063/5.0131930 is OK
- 10.1098/rsfs.2011.0026 is OK
- 10.1148/radiol.11111417 is OK
- 10.1063/5.0043822 is OK
- 10.1109/JOE.2018.2853199 is OK
- 10.1073/pnas.1606915113 is OK
- 10.1039/C2LC20861J is OK
- 10.1080/14786440808635681 is OK
- 10.1115/1.4009975 is OK
- 10.1121/1.384720 is OK
- 10.1016/j.ultsonch.2020.105307 is OK
- 10.1121/1.2118307 is OK
- 10.1063/1.4817673 is OK
- 10.1016/j.ultras.2005.03.010 is OK
- 10.1121/1.2109427 is OK
- 10.1016/j.ultrasmedbio.2021.06.012 is OK
- 10.1016/0771-050X(80)90013-3 is OK
- 10.1063/1.4945981 is OK
- 10.1063/1.1701962 is OK
- 10.1098/rspa.2009.0594 is OK

MISSING DOIs

- 10.5962/bhl.title.48411 may be a valid DOI for title: Underwater Explosions
- 10.21236/ad0403347 may be a valid DOI for title: The Collapse of a Spherical Cavity in a Compressible Liquid

INVALID DOIs

- None

from joss-reviews.

@fabiandenner can you check on those potentially missing DOIs in the paper?

from joss-reviews.

@kyleniemeyer One of the missing DOIs, for the book Underwater Explosions is spot on, well done editorialbot. I've added it to the bib file. Regarding the bot-suggested DOI, for the report The Collapse of a Spherical Cavity in a Compressible Liquid, it does not seem to work. However, the Cal Tech address in the reference is supposedly a persistent identifier provided by Cal Tech.

from joss-reviews.

@editorialbot generate pdf

from joss-reviews.

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

from joss-reviews.

Great! looks good to me.

from joss-reviews.

@editorialbot recommend-accept

from joss-reviews.

Attempting dry run of processing paper acceptance...

from joss-reviews.

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

OK DOIs

- 10.1146/annurev.fl.09.010177.001045 is OK
- 10.1088/0034-4885/73/10/106501 is OK
- 10.1146/annurev.fl.19.010187.000531 is OK
- 10.1016/j.ultsonch.2022.106131 is OK
- 10.1016/j.ultsonch.2020.105441 is OK
- 10.1016/j.jmatprotec.2022.117586 is OK
- 10.1016/j.ultsonch.2016.12.012 is OK
- 10.1021/acs.chemrev.1c00622 is OK
- 10.1007/978-94-017-7255-6 is OK
- 10.1016/j.ultrasmedbio.2020.01.002 is OK
- 10.1103/RevModPhys.74.425 is OK
- 10.1017/jfm.2022.202 is OK
- 10.1021/acs.chemrev.1c00438 is OK
- 10.1073/pnas.1019623108 is OK
- 10.1557/mrs.2019.107 is OK
- 10.1038/s41598-017-14312-0 is OK
- 10.1098/rsif.2015.0930 is OK
- 10.1016/j.chaos.2008.04.011 is OK
- 10.1063/5.0131930 is OK
- 10.1098/rsfs.2011.0026 is OK
- 10.1148/radiol.11111417 is OK
- 10.1063/5.0043822 is OK
- 10.1109/JOE.2018.2853199 is OK
- 10.1073/pnas.1606915113 is OK
- 10.1039/C2LC20861J is OK
- 10.1080/14786440808635681 is OK
- 10.1115/1.4009975 is OK
- 10.1121/1.384720 is OK
- 10.1016/j.ultsonch.2020.105307 is OK
- 10.1121/1.2118307 is OK
- 10.1063/1.4817673 is OK
- 10.1016/j.ultras.2005.03.010 is OK
- 10.1121/1.2109427 is OK
- 10.1016/j.ultrasmedbio.2021.06.012 is OK
- 10.1016/0771-050X(80)90013-3 is OK
- 10.5962/bhl.title.48411 is OK
- 10.1063/1.4945981 is OK
- 10.1063/1.1701962 is OK
- 10.1098/rspa.2009.0594 is OK

MISSING DOIs

- 10.21236/ad0403347 may be a valid DOI for title: The Collapse of a Spherical Cavity in a Compressible Liquid

INVALID DOIs

- None

from joss-reviews.

👋 @openjournals/pe-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#4315, then you can now move forward with accepting the submission by compiling again with the command @editorialbot accept

from joss-reviews.

Looks all good to me.

from joss-reviews.

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

from joss-reviews.

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:

cff-version: "1.2.0"
authors:
- family-names: Denner
  given-names: Fabian
  orcid: "https://orcid.org/0000-0001-5812-061X"
- family-names: Schenke
  given-names: Sören
  orcid: "https://orcid.org/0000-0001-8765-3722"
doi: 10.5281/zenodo.8043400
message: If you use this software, please cite our article in the
  Journal of Open Source Software.
preferred-citation:
  authors:
  - family-names: Denner
    given-names: Fabian
    orcid: "https://orcid.org/0000-0001-5812-061X"
  - family-names: Schenke
    given-names: Sören
    orcid: "https://orcid.org/0000-0001-8765-3722"
  date-published: 2023-06-15
  doi: 10.21105/joss.05435
  issn: 2475-9066
  issue: 86
  journal: Journal of Open Source Software
  publisher:
    name: Open Journals
  start: 5435
  title: "APECSS: A software library for cavitation bubble dynamics and
    acoustic emissions"
  type: article
  url: "https://joss.theoj.org/papers/10.21105/joss.05435"
  volume: 8
title: "APECSS: A software library for cavitation bubble dynamics and
  acoustic emissions"

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.

from joss-reviews.

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

from joss-reviews.

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

from joss-reviews.

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

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

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

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

from joss-reviews.