JOSS-Review

[parikshitbajpai]

Reviewing the Singularity-EOS paper for JOSS (openjournals/joss-reviews#6805), I came across a couple of minor typos and a couple of suggestions

• I didn't find any example usage on the documentation website. While the example directory contains the examples, it would be nice to have them on the documentation site as well including instructions on running them. This is something that can be done in a future release and doesn't necessarily have to be done as part of the review.
• In the paper, would you consider reorganizing the Statement of need and State of the field sections? I think the first paragraph of the state of the field section very clearly states why Singularity-EOS is needed, i.e. lack of unified APIs and GUI-support in other models. I'm not sure if moving that line to the statement of need section is the best idea but maybe you can figure out the best way of doing it.

[parikshitbajpai]

Also, as I was reviewing the paper, I noticed there's a few typos in the paper and documents, e.g. descriptions multi-phase descriptions:

singularity-eos/joss-paper/paper.md

Line 113 in 91ee692

sophisticated descriptions multi-phase descriptions of the lattice

I have made these changes locally as I was reviewing so please let me know if you prefer I open a PR with those changes, send you a patch or list them out here so you can fix those?

Thanks!

[Yurlungur]

Also, as I was reviewing the paper, I noticed there's a few typos in the paper and documents, e.g. descriptions multi-phase descriptions:

singularity-eos/joss-paper/paper.md

Line 113 in 91ee692

sophisticated descriptions multi-phase descriptions of the lattice

I have made these changes locally as I was reviewing so please let me know if you prefer I open a PR with those changes, send you a patch or list them out here so you can fix those?

Thanks so much, @parikshitbajpai ! A PR would be very welcome. :) However, I'm happy to use another method if you prefer.

[Yurlungur]

I can add documentation on the examples, and reorganize the paper hopefully over the weekend. Thanks for the suggestions!

[parikshitbajpai]

Thanks so much, @parikshitbajpai ! A PR would be very welcome. :) However, I'm happy to use another method if you prefer.

For sure, I can submit the PR tonight or tomorrow.

[Yurlungur]

@parikshitbajpai

In the paper, would you consider reorganizing the Statement of need and State of the field sections? I think the first paragraph of the state of the field section very clearly states why Singularity-EOS is needed, i.e. lack of unified APIs and GUI-support in other models. I'm not sure if moving that line to the statement of need section is the best idea but maybe you can figure out the best way of doing it.

Looking at the paper again with fresh eyes I almost wonder if switching the statement of need and state of the field sections might work. This leaves the definition of an equation of state until later in the paper, but it frontloads the reason to use singularity-EOS. What do you think?

[Yurlungur]

Alternatively, looking at the JOSS documentation, it seems that I could simply fuse the statement of need and state of the field sections into a single statement of need section.

[parikshitbajpai]

In the paper, would you consider reorganizing the Statement of need and State of the field sections? I think the first paragraph of the state of the field section very clearly states why Singularity-EOS is needed, i.e. lack of unified APIs and GUI-support in other models. I'm not sure if moving that line to the statement of need section is the best idea but maybe you can figure out the best way of doing it.

Looking at the paper again with fresh eyes I almost wonder if switching the statement of need and state of the field sections might work. This leaves the definition of an equation of state until later in the paper, but it frontloads the reason to use singularity-EOS. What do you think?

@Yurlungur,

I think either of the options you mentioned work. Maybe merging the two is a good way to go since the two sections appear to be tightly linked but you can pick whichever you prefer. Perhaps, @kyleniemeyer and @snikolov3 can chime in and suggest if they prefer one way or the other.

[Yurlungur]

@parikshitbajpai please take a look at #394 and let me know what you think.

[parikshitbajpai]

@parikshitbajpai please take a look at #394 and let me know what you think.

Thanks for adding the doco. It looks great to me and addresses both the points I raised.