JOSS review comments

[athulpg007]

Paper Comments:

• The paper is very-well written, and the code is well-documented.
• My recommendation is to include at least a couple of figures in the paper which illustrate the capability of the SONIC package to real world problems. Examples include: 1) the Synthetic Star Image of Arcturus, and its surrounding starfield, 2) smear removal of the Bennu asteroid image, 3) intensity of the image over a scan line, 4) Vesta 3D reconstruction. Including some of these figures in the paper, in my opinion would enrich the quality, and offer a preview of the capabilities to a diverse, non-specialist audience reading the paper.

Code Comments:

• The code is generally well-written, and well-organized. The examples in the documentation clearly illustrate the applications.
• There are no unit tests for any of the methods in +sonic. Please consider adding some unit tests for at least some of the core methods, or provide a justification how the authors verified the functions used are implemented correctly.
• There are no integration tests which exercise multiple methods used in a workflow. Please consider adding some integration tests, or alternatively provide a justification (for example: can the software reproduce some published results elsewhere?)
• "Note: As of 5/16/2024, SONIC has a few MATLAB toolbox dependencies which will require installation prior to full operation."
  • [optional] Instead of a hard-coded date, consider creating a tagged release, and use the version tag here instead (eg: v1.0)
  • [optional] consider replacing "SONIC has a few MATLAB toolbox dependencies" with "SONIC requires the following MATLAB toolboxes installed."
  • please specify the minimum required versions for the two dependencies, and if the latest versions are preferred.
• There are no community guidelines for contributions. Please consider adding a minimal CONTRIBUTING.md: https://github.com/astropy/astropy?tab=readme-ov-file#contributing-code-documentation-or-feedback

Minor comments:

• The first reference appears it should be "Astrometry.net", instead of "Astronomy.net"

[athrasher7]

Thank you for your review!

Paper Comments:

• I have added three figures to the paper that I think are useful for a new reader who hasn't looked at our repository yet. Each picture has a caption highlighting what was done (despite reading documentation, I'm not confident on how the captions are formatted). I included a new paragraph encouraging readers to run the examples locally to see how they work.

Code comments:

• We did much of our unit testing and general testing in a private repo to avoid cluttering the public repo. We would rather not upload these for the main reason that there are so many, and it would just be distracting for the average user. Where would you recommend that we add information on how unit testing was conducted, and what information are you looking for specifically?
• The workflows provided have references included for the user to check our implementation for themselves - the math and approach is intentionally transparent. There are many integrated capabilities, and a lot of them will be unique to a use case. Because of this, I'm not sure of an efficient way to show integration testing beyond providing the examples we did. Are there specific interactions you would recommend we include, or more information than the references we should add?
• The time tag was removed, and the versions used for development were added. We can't guarantee older or newer versions will work at this time. I changed the wording to your suggestion as well in the readme.
• We are in contact with our office about their stance on contributions. We will upload information to the readme once we hear back.

Minor Comments:

• Fixed

[athulpg007]

Thank you for the updates.

• Please re-make the PDF using @editorialbot generate pdf in https://github.com/openjournals/joss-reviews/issues/6916. I tried to do it, but the workflow ran into a error.
• It is considered good practice to have unit tests for the methods in a tests/ directory at the root. This allows for a regression test suite to ensure future changes/contributions do not break existing functionality. If you prefer to not have the unit tests, that is still acceptable. Please provide an explanation as to how internal users/contributors can verify they do not introduce bugs in the future. One suggestion would be to "run all the examples locally and compare the outputs to the pre-run demos in the SONIC API documentation" if any changes are made, plus "add an example illustrating any new functionality".
• The workflows provided in the examples are sufficient for integration tests.

I will re-review the paper once the PDF is available, and you hear back about contribution guidelines.

[athrasher7]

Happy Friday,

I have added a contributions file, which is pretty minimal right now, but subject to include more information about pull requests later.

I am having difficulty figuring out why the PDF will not generate. It seems like it doesn't like the inline citations, but it looks to me like they are in proper markdown format (i.e. [@refNameHere]). I've read through the documentation and can't find what's wrong. Do you have any guidance on this?

The installation page asks users to run the examples to verify their installation using the prerun examples, and the contributions file asks contributors to create their own similar example and to re run the old examples to ensure they still work.

[athulpg007]

Could you try if this example works? If yes, please replace the image URL and caption accordingly.

![](https://i.imgur.com/3XPh6JY.png)
**Figure 1.** An example of a Venus aerocapture vehicle trajectory and the stagnation-point heating profile computed by using AMAT. 

Also, see if the changing the image URL to: https://raw.githubusercontent.com/opnavlab/sonic/main/paper/scan_lines.png makes any difference.

[athulpg007]

The contributions section is adequate, thanks.

[athrasher7]

The problem was the link. The new link you provided fixed the issue. Thanks!