General

This manuscript describes a new version of the Community Coupler, C-Coupler3.0, used in Earth system modeling. It introduces new features, namely distributed grid data management, (model-internal and external) communication and remapping, as well as some new APIs for module integration, including DA methods. With very high-resolution data-driven simulations becoming more possible and common in ESM modeling, these improvements bring significant improvements to the previous version and make it a potentially competitive coupling algorithm.

The paper is well written and structured. It discusses the shortcomings of the previous version, followed by details of the innovations of the new one, including tests that mostly support the statements in the paper about performance improvements and accuracy retention. The code and tests are well documented.

One missing component is a discussion in the context of other current operational ESM Couplers (discussed below), which makes it difficult to judge how much of a contribution C-Coupler3.0 is to the field of ESM modeling as a whole. 

Specific Comments

- It would be better to provide many more comparisons with existing couplers used in other models (e.g., GFDL model’s coupler, OASIS or CESM’s CMEPS). The authors do conduct one simple test with CESM's air-sea flux algorithm, which is on the same grid as the model. The air-sea flux algorithm is then replaced with the C-Coupler’s module integration framework, and it is confirmed that both flux passing algorithms produce the same bit-wise results. Though reassuring, this is not a sufficient test to show C-Coupler’s competitive advantage. Most of the other performance and sensitivity results are compared with the old C-Coupler version. It would be fairer to compare with other distributed new-generation couplers, in terms of performance, usability and accuracy (and property preservation, e.g., during remapping and grid triangulation, see Ullrich and Taylor, 2015). Such a discussion with a clear summary of quantitative advantages of C-Coupler3.0 would be more helpful for entraining new potential users and for increasing the impact of this code/paper. 

Small clarifications/typos

- remapping code files (many places in .h and .cxx files): weigt -> weight

- P3, L31: point 2 and point 3 seem to be very similar

- P7, Common halo-exchange library: please clarify what is already in v2.0 and what is new in v3.0. It is only the checksums APIs and global halo indexing (instead of the special value labels) that are new?

- P15, L8: “… it should be much faster than the I/O on which the DA data exchange in an offline DA system depends” This point could be modified and clarified.

Reference

- Ullrich and Taylor (2015) https://journals.ametsoc.org/view/journals/mwre/143/6/mwr-d-14-00343.1.xml 

"C-Coupler3.0: an integrated coupler infrastructure for Earth system modeling" provides a nice overview of the newest version of the C-Coupler, version 3.  Several new features are described and results are presented.  Several configurations and resolutions are presented effectively.  The paper is concise, well organized, and well written.  I have some concerns about the description of the module-integration framework and suggest that section be reviewed further.  Implementation of the new parallel algorithms are not described in any detail.  If there is something new there that is not described in other references, it might be useful to include it.

Specific Comments:

Each grid has 3 distributions (index, domain, parallel-decomposition).  The native model decomposition is the parallel-decomposition in each component.  I assume the 3 distributions for each grid only exist in the coupler component and they are all stored there and that the domain decomposition is mostly used to generate mapping weights files which is done at iniitialization?  Why save all 3 distributions in the coupler, why not just use the index distribution in the coupler permanently and allow the other 2 to be temporary?

Does the halo exchange implementation impose any constraints on the width of the halo?  If not, maybe mention that explicitly in secton 3 under advantages on page 8.

I assume the checksum (page 8) ultimately requires an MPI global reduction, so this is primarily for testing and debugging?

The module-integration framework description is not very clear.  Ultimately, I had a look at the atm_ocn_flux_ccpl code.  It looks like you just add extra layers to the implementation, but you still have to pass all the same native coupler variables into the framework and then unpack/pack the data and pass it to the lower level shr_flux_atmocn subroutine.  In this example, I see very little benefit to the extra framework layer.  Maybe in cases where different decompositions are used, it is helpful, but the benefits are unclear.  It looks like you need to implement a unique framework layer for every caller and callee combination, I don’t imagine there is a lot of code reuse advantage.  If that’s the case, why have it?  You argue independence and convenience.  Maybe there is some advantage, but the downside is having to develop the extra layer(s) of code for all instances of it’s use and match the framework and DLL requirements.  You could also just have a layer in-between that translates data types without all the framework and DLL stuff.  What extra benefits does the framework and DLL provide and is the extra layer(s) really better than just having a copy in/out at the top of the subroutine being called?  Finally, the flux_atmocn APIs don’t seem to match what is documented in the appendix.  Why?

Page 9, line 9.  The next few lines seem to discuss subroutines that are called on columns of data.  That is really just a minor class of types of methods that might be called.  I don’t think that restriction is necessarily related to the module-integration framework.  You might be trying to say the module-integration framework is more flexible than CCPP.  If so, say that, NOT page 9 lines 9-16.

In table 1, is the coupling initialization time including reading mapping weights?  The remapping weight generation time is done with a separate test?

In Table 2 and 3 captions (and section 7.2), you say “the halo region on each process has two/four levels”.  Please clarify what “levels” means.  Is that the width of the halo?

The results are presented primarily as MB or GB per second.  Can you provide an idea of the typical overhead associated with coupling for some working systems for C-Coupler3?  Is it 0.1%, 1%, 5%, 20%?  How does that compare to a similar application using C-Coupler2?

You are missing the following references in your References list on page 16, Balaji et al 2006, Craig et al 2005, 2012, 2017, Jacob et al, 2005, 

p1, line 23, error, 20012?

p3, line 4, use “output” instead of “outputted”