Manuscript review

[amandadumi]

This pull request is being made as part of the JOSS review https://github.com/openjournals/joss-reviews/issues/4623.

This is a very nice tool, and the contribution to the community is very nice. I read the paper before looking at the documentation tutorials to see if the impression/understanding of the tool was clear enough. So although some of this may be clarified in documentation, it may not be clear within the manuscript alone.

General structure points, which would fall under the "quality of writing" portion of the review. The other portions of the paper are fulfilled in my eyes.

• 26: “elaborate coding” implies some base level of coding for all runs, is that true or can one just call this command line with no change to the code?
• 29: the phrase “and it’s applications” seems more confusing than helpful. It seems you are referring to the methods and modules implemented within the library, but applications is vague and could point to specific system use cases or Possibly just the many features, or completely separate code bases. I think dropping the phrase let’s this sent nice be more clear/accurate. If you wanted to reword it, that’s fine too.
• 31: “allow to run” reads strangely since there is no subject. “allow one to run” would be fine.
• 35:"and it’s available applications” seems unnecessary here just as above on line 29 as I’m unable to differentiate between the differences in implementations vs applications.
• 35: “allow to run” since there is no subject. “allow one to run” would be fine
• 39: are solvers an implementation in TRIQS or is this within your project. This is cleared up later in the article, but could be clearer in this sentence. As it’s currently written it seems that only new features from TRIQS are tested but the solvers are inherent to solid_dmft
• 41: “run on top of a DFT calculation” is vague…are results imported through an expected format/API or is a feature of solid_dmft that it can act as a drive for other codes. Further in the paragraph it is explained that results are imported from other codes through a conversion script to HDF5, but saying this in the first sentence would clear things up.
• 46: this is a question that comes from my unfamiliarity with the details of this method. It makes sense that you are going from momentum space to localized real space orbitals, but is this actual though the combinations of multiple different wavefunctions for a single representation in kspace? Initially I would have guessed a single wave function would have been needed, but I’m still learning for this level of detail.
• 49: sentence has two unrelated points, although both are important.
• 49: Green’s functions, not Green functions
• 52: allows to
• 57: Reword as interfaces since it is interfacing with multiple codes
• 59 allows to → allows one to
• 62 Green’s function
• 65 1) “an updated documentation” feels a bit strange to read, for instance I wouldn’t say “we provide a documentation”. Instead removing the “an” or instead saying “providing an updated version of the documentation” both read better. 2) I’m not sure how documentation and reference manual are different. If I’m unfamiliar with this programming term, just let me know. It seems like you may be referring to the API definition. If that’s the case this may be better presented as a subsection of the documentation. 3) similar to the last point, this sentence implies the documentation and tutorials are separate, while in the following sentence it is implied that the tutorials are part of the documentation. Maybe a simple change to the first sentence of “updated documentation containing tutorials and an API definitions ” would are this clear.
• 77: just saying “a flagship implementation of TRIQS” implies solid_DMFT is reprogramming tools available in TRIQS instead of interfacing or utilizing the library, instead the a more accurate phrasing would be “an interface to the flagship implementations contained within the TRIQS software”.

[merkelm]

Thank you for the feedback! We changed the paper accordingly in the pull request #26 on the joss branch, together with a few changes related to issue #23. The only bullet points of yours we did not address by changing the paper are the following (numbers referring to the line numbers you used in this issue):

• 46: We construct the localized orbitals from the single-particle Kohn-Sham wavefunction from DFT. This can be achieved by either projecting on localized atomic-like orbitals or more elaborate wannierization procedures.
• 49/62: According to Wikipedia, both Green's function and Green function are acceptable. We decided to go for Green function here to be consistent with other terms, such as Hubbard U, Lorentz transformation, etc
• 65: For 2), we stuck to the term "reference manual". The difference is that a documentation provides higher-level overview while a reference manual documents the behavior of functions or classes in the source code. We updated the paper following your points 1) and 3).

[amandadumi]

Thank you for the update. The use of reference manual makes sense, the context on the use of "wave functions" in your first point gives the context I needed. I had never seen the phrase Green function used so thanks for clarifying, I'll keep that in mind moving forward.

This all looks good and comments have all addressed, thank you!