This is a good description of what sounds like an elegant and useful numerical tool for modelling coupled hydro-geomechanical processes in heterogeneous subsurface environments. I like the model. I think other researchers in the field will find great value in it as well. The modelling results are impressive.

My point of concern is that the authors, in justifying the raison d’etre of this publication, seem to imply that the list modelling platforms they discuss in the build-up is exhaustive. I know this is not stated explicitly. It is implicit though. In fact, the authors list is, I presume, simply based on their experience. My point is that the list does not have to be exhaustive (in my opinion), but I would advise the authors to state this more clearly.

I cannot seem to find any statement regarding the computational effort of this code. I would consider this important information.

The examples are in 2D. What is the practical feasibility – both in terms of availability of information/data and in terms of computational effort -- of such simulations in 3D?

Line 74: “ However, a more robust implementation is Porous Flow, …” I cannot say whether this statement is true or not, but I suggest that the authors buttress such statements with facts. Why is PorousFlow the more robust implementation and where has this been shown?

Line 82: I cannot see why the MOOSE naming convention or which kind of bird Rhea is should be relevant to the reader.

Dear Sir/Madam,

I read with great interest the manuscript entitled "RHEA v1.0: Enabling fully coupled simulations with hydro-geomechanical heterogeneity" by Espejo and co-workers. In the study, the authors presented an automatic workflow (at least that is my impression) to create input files to be used by an existing physics module developed within the MOOSE framework.

Despite I acknowledge the efforts from the authors, I am adivising for a major revision before the paper can be consider for its publication in GMD. The main criticism is that the paper lacks the scientific novelty required to make a major contribution to the related community. This is not a limitation of their approach (I think), but rather stems from the authors' choice of the examples discussed in the paper. Indeed, while claiming that their workflow contribute to advance the scientific computing efforts for complex subsurface applications, they limited their discussion to simplistic analytical examples. Terzaghi consolidation is a relatively simple benchmark, which should only be used to validate the physics implementation of their numerical tool. However, this is not the topic of the manuscript, given that the authors relied on existing modules (Porous Flow and Tensor Mechanics). Their realistic example is also a synthetic and simple one, 2 dimensional and with no clear tangible application. 

I am saying this, cause the reader is left with the (wrong?) impression that the main contribution of the manuscript is the development of a python script binding MOOSE's objects, which to my opinion does not satisfy the minimum scientific level for a publication (it would rather fit as an internal report). This said, I would warmly advise the authors to re-organize the manuscript in a way to better convene the main message of their work, and, in doing so, to prove their generic sentencing  as "... Our work is a valuable tool to assess challenging real world hydro-geomechanical systems that may include different levels of complexity like heterogeneous geology with several time and spatial scales and

sharp gradients produced by contrasting subsurface properties. ...", for which I could not find any concept of proof in the text.

More specific comments:

* Abstract - sentence at lines 4-5 - it requires some reworking. Stating that there are no simulations considering heterogeneity in the subsurface is simply not true (an extensive literature research is required here). In addition, it is not clear what they mean by "verification".

* Introduction - sentence at lines 26-27 - also this sentence is not true ("infeasible").

*Introduction - sentence at lines 65-67 - The coupling among physics is not done automatically but via off-diagonal components in the system's Jacobian matrix.

* Paragraph 3 - sentence at line 136 -Material properties are defined at the element level by default in any FEM application.

* Paragraph 3 - sentence at line 155 - Why the size of the mesh needs to match the coverage of the sampling data? Is that a limitation of a naive implementation of the interpolation routine used within the workflow?

* Why rephrasing equation 8 in terms of the hydraulic conductivity? It does not match the formalism used in the previous paragraph ...

General comments

The manuscript describes a new contribution to the modelling of hydro-mechanical problems in form of a MOOSE-based simulator. While I think that it deserves publication in GMD, it needs substantial improvements as outlined below. This particularly concerns Section 3 which should be made much more detailed and explicit to be of any value. Moreover, the literature review on existing implementation efforts should be considerably improved. So far, it arbitrarily picks three open-source packages and discredits them with oversimplifying statements.

Specific comments

- l.44ff: I don't agree with this statement. The mentioned references indicate that more sophisticated sequential schemes like iterated fixed-stress perform quite well. It's the "naive" or "straightforward" approaches like drained-split or non-iterated fixed-stress which might perform poorly. Please rephrase.

- l.55ff: There's a more recent "official" paper on PorePy which is better to cite than the 2017 one: https://link.springer.com/article/10.1007/s10596-020-10002-5. I think that the statement "these codes are in an immature stage" doesn't properly reflect the apparently rather big efforts behind, at least, PorePy. I'm also not sure about the argument with the "point and line sinks", maybe they have already been integrated or maybe it's very easy to integrate them as a user of the framework. To me, the intention of these codes is just very different from company efforts like COMSOL or coupling frameworks such as MOOSE and probably not what the authors need or aim for. 

- l.60f: I also don't like the negative statements here or at least the general way in which they are formulated. I'm sure that the developers of OpenGeoSys would disagree. It's open source, anyone can adapt the "fundamental governing equations" to her needs. In principle. Please relate things with something like "from our experience, it's rather difficult to..."

- The list of other mentioned packages is very short and subjective. There are many other efforts for hydro-mechanical modelling based on other frameworks, such as

  * https://doi.org/10.1016/j.cam.2016.10.022 or https://doi.org/10.1142/S1793962321500033 based on deal.II

  * https://doi.org/10.1007/s10596-020-09987-w based on Dumux

  * https://doi.org/10.1029/2019JB017298 based on MRST

  * PFLOTRAN can do geomechanics: https://www.pflotran.org/documentation/theory_guide/mode_geomechanics.html

  All of these frameworks can deal with heterogeneous material parameters.

- l.67: What are "gold-standard numerical solvers"?

- l.70f: "for example an experienced user can easily modify the source code to add desired features such as..." I'm convinced that this also holds for the open-source codes which are mentioned above and which have been put in a negative light.

- Section 3 does a very poor job in describing the implementation of the model, as it doesn't connect enough to Section 2. There's only a few lines 135ff which make an explicit connection, the rest is generic blabla. I consider this the most important section of the manuscript. Please be much more precise here. How are the two modules integrated? How are they coupled? What finite elements are used? What time integration scheme? What about local mass conservation?...

- l.349: I saw that you are required to link to Zenodo. That's ok, but please keep also the link to GitHub, that's where your code is developed further, hopefully.

Technical corrections

- l.32, 92, 102, ...: a single "porous mediUM", many porous media

- l.161: "designED"

- l.189: "undraiNed"

- (19): "L" instead of "H"

- l.336: "play" without "s"