Review JOSS - BR

[RiesBen]

JOSS Review: https://github.com/openjournals/joss-reviews/issues/6970

Hi I looked through you submission. In general the repository looks good to me! I installed the package and tested the unit tests. For the submission I have the following comments & suggestions:

• Repository
  • Readme:
  • [x] Install Section should explain the steps, as there is an additional program installed. This is important for totally new users.
  • [x] Suggestion: Indicate, that the box after the code example is the output.
  • [x] Setup.py: Authors and Emails missing
  • [x] Environment.yml: Could it be that GOMC is missing? If you state here in the docs, it is an requirement (https://mosdef-dihedral-fit.readthedocs.io/en/latest/getting_started/quick_start/quick_start.html#), then it should be part of the environment. (could also make binary detection easier)
  • [x] Documentation: Repository Doc strings - API Rcference Docs missing? (can be generated with sphinx-apidoc)
  • [x] file_read_and_write.py: If I see it correctly this one contains unused imports.
  • [x] License File: if you change the formatting, then GitHub can recognize the license file (e.g.: https://github.com/OpenFreeEnergy/kartograf/blob/main/LICENSE)
• Paper:
  • [x] Line 12-24: Introduction
  • [x] line 12: MD and MC are just two examples, you could indicate this with e.g.
  • [x] Line 12-14: I find the categorization of theoretical, simulation and experimental scientific methods a bit confusing and would like to offer the following view: "There are theoretical and experimental methods, in the theoretical regime we can distinguish between analytical and stochastic methods. Stochastic methods can be for example simulation approaches. In the regime of MM the size of the phase space of more complex systems makes analytical methods very hard to calculate certain properties. However if well converged simulations allow to observe the relevant parts of the phase space and therefore give important estimates of certain properties. ..."
  • [x] Line 15: what are conventional methods here? I'm not a native speaker, but I have the impression that difficult and unattainable is saying kinda the same? (too expensive as well)
  • [x] Line 19: QM parameters are nice if used in forcefields, but they are not necessarily a requirement (GROMOS - FF, etc.).
  • [x] Line 12-24: You should back up your text with literature, here.
  • [x] Line 39 - 40: I'm not sure I understand why turning off other contributions makes the dihedral fit more accurate, can you elaborate please?
  • [ ] Line 87-88: Your claim here needs to be supported by literature here.
  • [x] Line 100-103: I would like to suggest for the equations to use physical meaningful symbols as targets quantities (U or V). Examples: V{dihedral}^{OPLS}(\theta) (instead of OPLS{Energy}), V{dihedral}^{RB}(\psi), V{dihedral}^{Periodic}(\theta)
  • A general remark: I think the Introduction and statement of need are a bit repetitive, maybe you could slim down the paper a bit?

[bc118]

Hello! Thank you for your review and comments! We will complete all of these that are feasible to completed. We started a issue checklist with all the reviewer comments, so we can address them and write our teams notes here #101. Feel free to review this checklist also.

[bc118]

@RiesBen Hello! I hope you are doing well. We are working to finish this, have made a lot of progress, and are getting close to completing it. I do have the following question (s):

For this comment "Documentation: Repository Doc strings - API Reference Docs missing? (can be generated with sphinx-apidoc)":

• The user's main functions existed but are _not labeled as functions but data structures_ for the software, and they cover all the possible combinations of variables that the user can enter, checking them and providing very informative error outputs. The main functions are (i.e., data structures) .

• I added all the _additional utilities_, which are not intended to be used for the direct application of this software. Is this what you were suggesting here or did you only want the main user function (i.e., data structures in the above)?

It would be much appreciated if you could clarify this so I can make sure it is what you are suggesting Can you or let me know if adding the additional utilities what you were thinking or simply keeping the _data structure_s (i.e., main functions)?

Thank you again for your time on your review and your comments that made this software package better!

[RiesBen]

Hi @bc118 , a right, this is the section I was searching for! cool, that you added the additional utilities! :) I think both in something like API reference or so would be the correct section, no? Why is it actually Datastructure? Isn't this more a code structure or API reference section?

[bc118]

Hi! Ah, yes. In the docs titles/labeling, we have tried to keep it consistent across the MoSDeF software family (mbuild, foyer, gmso, forcefield-utilities, and MoSDeF-GOMC, etc.) and Data structures was what we have been using for this section. I was not around for the original naming of the sections, but I suspect it means how they need to structure the input data and what to expect the output or attributes in the classes.

I also added a few other features (force to k0=0 for OPLS form or a constant) and a lot more examples.