Here a leave a few corrections that would be nice to make to the submitted JOSS paper.
Constituents of the Lherzolite
The following sentence lists the constituents of Lherzolite as an example. I suggest the authors to introduce the acronyms before using them, so they are clearer to a broad audience that isn't too familiar with them.
For instance, one can create a Lherzolite material by mixing specific modal proportions of ol, opx, cpx and gt, how these constituents are interconnected [...]
For example, it can be updated as follows:
For instance, one can create a Lherzolite material by mixing specific modal proportions of olivine (ol), orthopyroxene (opx), clinopyroxene (cpx), garnet (gt), how these constituents are interconnected [...]
Harmonica citation
The paper that is being cited when mentioning Harmonica is Soler et al. (2019). Gravitational field calculation in spherical coordinates using variable densities in depth. In order to cite the Harmonica library, I suggest the authors to use the doi specific for the software library:
Fatiando a Terra Project, Castro, Y. M., Esteban, F. D., Li, L., Oliveira Jr, V. C., Pesce, A., Shea, N., Soler, S. R., Souza-Junior, G. F., Tankersley, M., Uieda, L., & Uppal, I. (2024).
Harmonica: Forward modeling, inversion, and processing gravity and magnetic data.
Zenodo. https://doi.org/10.5281/zenodo.3628741
Improve sentence
The following sentences introduce the ability of pide to generate synthetic MT and seismic velocity models:
However, it can only generate synthetic magnetotelluric and seismic velocity models since their forward modelling is not as easy to implement within the pide framework. Currently, pide can generate input files for commonly used magnetotelluric modelling algorithms ModEM and Mare2DEM, and then users can generate synthetic data using the algorithms themselves with the given synthetic model.
The way the sentences are written undersells the current capabilities of the software. Instead of focusing on the outputs pide cannot currently produce, I would suggest the authors to focus on the features it already ships. So, for example, these sentences could be rephrased to something like:
Pide can generate synthetic electric conductivity and seismic velocity models that can be saved as input files for commonly used magnetotelluric modelling software like ModEM and Mare2DEM. Users can then generate synthetic data using the algorithms provided by these software packages.
Flow chart
The flow chart showcased in Figure 1 highlights some of pide classes and modules, and how they can be used in a workflow to generate the different outputs. Nonetheless, when referring to these classes and modules, the name of the .py files where they live are shown in the text boxes.
The .py files where the classes and functions live is not something too relevant for the users: they don't need to know the internal structure of the source code, just how to interact with it. Moreover, the internal structure of the source could change, while keeping the API of the library intact.
Therefore, I would suggest the authors to focus on mentioning which classes and functions should be used in each stage of the workflow (omitting the .py files where they live). Moreover, I would differentiate between classes (model, Material, pide) and modules (grav, mag). This could be achieved by using different colors for the text boxes. Including a legend for such color code would also be beneficial (e.g. magenta for classes, cyan for modules, etc).
Typo
There's a typo in the following sentence, specifically in architechture:
pide also comes with several tools that can exploit the program architecthure.
Example in paper
In my personal opinion the paper ends a little bit abruptly after listing its capabilities. I think that the paper would benefit from having a last section showing one very small and simple example of what can be done with pide. It doesn't need as large as the one in the notebooks, but just to give a broad sense of how some of the listed features can be used, and what are their outputs.
[!IMPORTANT]
This is a subjective recommendation, so feel free to ignore it if you disagree with it. Not addressing this comment won't block the acceptance of the submitted article to JOSS.
Here a leave a few corrections that would be nice to make to the submitted JOSS paper.
Constituents of the Lherzolite
The following sentence lists the constituents of Lherzolite as an example. I suggest the authors to introduce the acronyms before using them, so they are clearer to a broad audience that isn't too familiar with them.
For example, it can be updated as follows:
Harmonica citation
The paper that is being cited when mentioning Harmonica is Soler et al. (2019). Gravitational field calculation in spherical coordinates using variable densities in depth. In order to cite the Harmonica library, I suggest the authors to use the doi specific for the software library:
Improve sentence
The following sentences introduce the ability of
pide
to generate synthetic MT and seismic velocity models:The way the sentences are written undersells the current capabilities of the software. Instead of focusing on the outputs
pide
cannot currently produce, I would suggest the authors to focus on the features it already ships. So, for example, these sentences could be rephrased to something like:Flow chart
The flow chart showcased in Figure 1 highlights some of
pide
classes and modules, and how they can be used in a workflow to generate the different outputs. Nonetheless, when referring to these classes and modules, the name of the.py
files where they live are shown in the text boxes.The
.py
files where the classes and functions live is not something too relevant for the users: they don't need to know the internal structure of the source code, just how to interact with it. Moreover, the internal structure of the source could change, while keeping the API of the library intact.Therefore, I would suggest the authors to focus on mentioning which classes and functions should be used in each stage of the workflow (omitting the
.py
files where they live). Moreover, I would differentiate between classes (model
,Material
,pide
) and modules (grav
,mag
). This could be achieved by using different colors for the text boxes. Including a legend for such color code would also be beneficial (e.g. magenta for classes, cyan for modules, etc).Typo
There's a typo in the following sentence, specifically in
architechture
:Example in paper
In my personal opinion the paper ends a little bit abruptly after listing its capabilities. I think that the paper would benefit from having a last section showing one very small and simple example of what can be done with
pide
. It doesn't need as large as the one in the notebooks, but just to give a broad sense of how some of the listed features can be used, and what are their outputs.