The authors of the article "The MESSy DWARF" describe The Modular Earth Submodel System (MESSy), a framework to integrate components to form an Earth system model. The topic of the article is an extension of the MESSy framework that simplifies the set-up and running of submodel(s) without the need for a full dynamical core to drive the simulation. Before this work, MESSy would always require a weather or climate forecast model as a "basemodel".

The underpinning concept of the presented approach is to substitute the basemodel and its role of providing the evolution of prognostic variables by a dummy component (the new submodel DWARFDCD). Prognostic variables are initialised to zero or, optionally, from input files and can be relaxed over time at a given rate. This approach provides other submodules with the relevant variables without the overhead of a basemodel, and its development is described as being inspired by the "dwarf strategy" developed and published in the ESCAPE project.

The authors highlight some differences to this dwarf strategy, namely the additional overhead incurred from always setting up a standard model with the entire coupling framework and infrastructure, which is notably more involved than the minimal drivers developed in ESCAPE, where each is bespoke to the corresponding component. This difference is being presented as an advantage because it allows to drive different components with the same setup. I do not fully subscribe to this point of view as the amount of required infrastructure is rather substantial, which can be a hindrance for technical exploration in experimental software stacks and the balance does not necessarily seem right for small submodels such as an individual microphysics parameterisation (one of the dwarves in ESCAPE). However, for larger submodels, e.g., related to atmospheric chemistry, which is a typical application scenario for MESSy, this seems less relevant, and overall I do agree that the gain in flexibility offers substantial advantages. In addition, one advantage that has not been listed explicitly, is the fact that the same submodel that has been developed and used with the DWARF can also be used without further changes coupled to a basemodel.

To me, the most substantial issue of the article is the structure and presentation of the concept and implementation. This starts already in the introduction, which does not sufficiently motivate the reasons why this development has been undertaken in the MESSy framework, and instead circles back-and-forth to the ESCAPE ideas and the similarities and differences. Pointing these out is valid but shouldn't constitute the basis of the work. Some of what I would have liked to read in this section comes in the first paragraph of Sec. 4 instead.

The introduction to the MESSy infrastructure and submodel concept in Sec. 2 is reasonably short and intuitive, with helpful pointers to additional resources for more details.

However, the description of the implementation in Sec. 3 dives immediately into technical details for individual infrastructure components of the MESSy framework. If this was instead motivated by the conceptual ideas of the dummy driver and the data requirements of a scientific submodel, it would benefit a wider audience beyond the users of the MESSy framework. This is notable, e.g., because more than once the relevant subsections start with statements similar to "usually this or that is defined/provided by the basemodel". In my opinion, if may suggest just one possibility: start with the description of the requirements of a hypothetical (or actual, as a case study) submodel component that is planned to be executed in a DWARF setting. Then explain how these inputs (e.g., prognostic variables), outputs (e.g., tendencies or diagnostic variables), and fundamental data structures (e.g., grid, domain decomposition), would be usually provided in the MESSy framework, thus highlighting the importance of the basemodel for many of these. And ultimately, detail how the DWARF setup and DWARFDCD replace the basemodel for providing these, amended with technical details about their implementation in the basemodel interface layer. Importantly, also include a description of limitations. Stubs of all this can be found in introductory paragraphs to Sec. 3 and some of it's subsections, but is immediately lost in-between the technical details. My hope would be, embedding this into a better carved out storyline would better convey the clearly well though-out concepts and flexibility of the solution.

This is also reflected in the description of the examples in Sec. 4: While these are well-suited to illustrate the capability of the approach and the presented results appear convincing, I am missing technical details that would provide a connection to the DWARF implementation description in the previous section. For example, what specific variables and data structures were required by the submodel and how did the DWARF provide them?

Finally, a few minor remarks to specific figures/parts of the manuscript:

• Figure 2 would benefit from some additional context in the caption, e.g., what nudging is active, what inputs are provided explicitly and which are omitted, etc. Moreover, I find the presence of commented namelist entries confusing (e.g., nudgedt_u).
• The labeling inside Figure 4 suggests that mgprow/mgpcol denote the number of grid points per direction, while the text in Sec. 3.2 refers to them as the number of grid boxes (which would imply the number of grid points is mgprow+1/mgpcol+1).
• The description of the decomposition in Sec. 3.3 is misleading: For example, "the latitude range covers 93 grid boxes, which are distributed among 2 tasks" is factually wrong, because these are distributed among 8 tasks. The latitude range is rather decomposed into two subranges, each of which is assigned to one of the two sets of compute tasks in latitudinal direction. The corresponding longitudinal range in each of these sets is then further subdivided and assigned to one of the four compute tasks assigned to the latitudinal subrange.
• The technical description of the performance benefits of the GPU port is incomplete. Performance numbers are presented without stating the used hardware (the mentioning of JUWELS-BOOSTER for the GPU numbers suggests that A100 GPUs were used but it is entirely unclear how many and to what CPUs this is being compared).
• The language is in some places rather informal, for example the use of "Anyhow" in the Code and data availability statement.

Overall, the presented work is substantial, the concepts appear sound and the benefits and applicability promising. But the presentation in the article would benefit from a clearer structure and storyline.

Review is attached as PDF.

The MESSy DWARF (based on MESSy v2.55.2)

Astrid Kerkweg, Timo Kirfel, Doung H. Do, Sabine Griessbach, Patrick Jöckel, 

and Domenico Taraborrelli

The paper describes the implementation of the submodel DWARF within the framework of the modular earth submodel system (MESSy) and its application in some exemplified test cases. The DWARF submodel allows the creation of a simplified model substituting the usually used dynamical base model in the MESSy framework. The advantage of this concept is having a simple test environment for the application, development, and performance testing of single submodels or a combination of submodels.

Overall it is a well-written paper, well suited for GMD and should be published after minor revisions.

General comment:

Describe in more detail the difference between DWARF and DWARFDCD at the beginning of Section 3. Maybe describe it in more detail, e.g., as done in the supplement on page 10.

Section 3:

Line 124 and line 149:

You mention the prognostic variables provided by the base model and restrict this to these of the equation of motion. It would be best if you wrote this more generally, as all these variables are integrated forward from the primitive equations.

Section 4:

Line 306/307:

“For the sake of simplicity they are kept constant in time.”

Does that mean that the tendencies are not added to the chemical tracers? 

Please clarify.

Technical correction:

Avoid setting an extra period in cases where the sentence ends with an abbreviation:

Line 78, Line 95

Change for clarity:

Line 137:

… a prognostic variable set … → … a set of prognostic variables …