This is a good paper addressing the important topic of concurrency that has so far not been explored enough in Earth system modelling. The paper is well written but could be more concise. The theoretical analysis is backed up with convincing performance measurements that show the usefulness of concurrency. The paper will be ready for publication in GMD if the following minor comments are addressed.

More significant points:

• Page 9 seems to be a broken in the published PDF. I opened the document with 3 different PDF viewers, but I never got to see the entire page.
• Overall, the document is longer than it would need to be. E.g. the model descriptions could be shortened as documentations to the models are provided as references. This is a subjective opinion by me, so feel free to disagree, but maybe you can consider making the document shorter.
• Section 3.2: This is a very interesting discussion. However, I am not sure how much of this is new and how much of this is common knowledge in computer science. If it is new, it should be made more prominent (e.g. in abstract and intro). If it is not new, maybe provide references more prominently.
• Figure 5: I am not a big fan of the figure. The left side is supposed to show a serial workflow but is showing two boxes in “parallel”. Why not add a time dimension to the figure and streamline the left side into a single line of tasks? Maybe you can also use the nomenclature of Section 3.2 (W,N…)?
• I am missing a bit more of a discussion what happens when the components are not strictly independent. E.g. when running the radiation scheme concurrently to the rest of the atmosphere model. The independence is quite a significant limitation for couple Earth system model components.
• Paragraph starting with L369: These seem to be quite significant limitations of the approach. Could you also provide timing results with GM parametrisation, IO etc. to give the reader an impression how significant the limitations are?
• Can you say anything about the energy cost when using concurrency (or not)? No big problem if not.
• Maybe I missed the information, but do you state somewhere how long the individual experiments were and how many you have run for each performance measure to reduce measurement errors?
• I am not quite sure whether you present results from the old and the new machine at DKRZ since it is useful (2 generations of machines), or just since the machine has changed in the meanwhile. Both would be OK but maybe you can justify somewhere.

Minor points:

L6-7: “The novel…” This sentence is a bit odd and “function parallel technique” is unclear at this stage.

L41: “…cannot efficiently scale” That is quite a statement. Can you provide a reference?

Figure 1: “sea-land mask is in color” ?

L113: Better say “local grid-spacings of 600m”

L158: Maybe it is just me, but I am not sure what a “trophic level” is.

L176: “and may only need… components” Is unclear and should be revised.

L190: “in of”

You could cite work of ESiWACE from a couple of years ago (but no worries if you disagree): https://zenodo.org/record/1453858#.Y0KPyi8Rp9c

L319: I do not understand this sentence and it should be rephrased.

L349: Is there a performance hit when guaranteeing bit-reproducible results? I assume this only holds if the concurrent parts are running on the same hardware?

L377: “No such effort…” I think this is an understatement. Maybe say that those parameters have not been optimised?

L410: si -> is

L474: “does not apply”. Well, I guess this is always only an approximation. -> “is a bad approximation due to the unusual super-linear…”

L513: remove “though”

The paper describes the effect of executing concurrently different components of an ESM in terms of performance: ICON-O + HAMMOC.  Each of the components are implemented as distributed memory programs  (MPI) with multithreaded inter-process execution (OpenMP). A mathematical model of the execution describes the trade-offs of running the components sequentially or in parallel, and gives an intuition on what are the constraints in the expected performance improvements. Performance evaluation is done on two model resolutions and two computer architectures, with an interesting analysis of the results that refers back to the model of execution. This gives the results a conceptual link that is too often neglected in the literature. The paper focuses on ICON-O and HAMMOC, that use the same grid. As a paper I have found it very informative and useful. The mathematical model is not very surprising at the end, but it offers a valuable baseline to reason about the results.

Some points for discussion:

- The abstract needs improvement in my opinion. Line 7 mention "function level parallelism". In the computer science literature the term used is typically "task parallelism", and it is opposed to "data parallelism".

- Would it be possible to explain in few words what are the limitations to scalability mentioned in in line 15 about "traditional parallelization techniques". I do not see the logical implication here, more so given that ICON-O and HAMOCC use the same grid. Is it a problem with software structure? That is, would an implementation with even less modularization (more monolithic) avoid this problem?

- As my main interest is in software architecture and engineering, I think it would be very interesting to me and useful to the community to expand on the implications that the software restructuring has on the code base. For instance it would be interesting to mention the (qualitative) effects of the ability to run sequentially or concurrently in terms of code maintainability and readability.

- I find the sentence in lines 214-215, about the fact that OpenMP does not incur in communication costs, not precise. It depends what communications we are considering. OpenMp can be quite costly in case of data to be access by different threads for instance. Maybe the sentence should specify that the communication cost refers to extra-node or extra-process communication.

- I find the paragraph in line 227 not very convincing, since it is not clear to me what "a high-level implementation" means here. Is it just because it focuses on MPI to transfer data between MPI ranks?

- In Section 3.2 I think the treatment could be improved by removing the subscript "p" from "a_p" and use instead the letters "A" or "B" to indicate to which component the value refers to. Also the parameter lambda should be introduced more specifically, since it not immediately clear why the same lambda is used in W_B and N_B. It can be deduced, but it becomes clear later in the text. This could be explained earlier. Similarly, the cost of concurrency "C" could also be introduced with an example of what it may include.

- The "at most linear" scaling seems to actually mean "monotonic", since F'(N)<=0.

- In Section 5 the Authors mention that they ran three times each experiment. It could be useful to report on the variability of the execution times in those three runs to justify the use of such small number. If other limiting factors were in place maybe it is worth mentioning.

- In Table 1 and 2 the lambdas are greater that 1, while in the mathematical analysis it is assumed to be less than 1. 

- The paper focuses on a simulation software with two components. Could a comment be made on the possibility, both in terms of software structure and performance benefit, of applying concurrency within the said components (I guess in "shared memory" style (see end of Section 3.1))?

- Line 259: I would use "assume" instead of "accept"