Coupling the regional climate model ICON-CLM v2.6.6 to the Earth system model GCOAST-AHOI v2.0 using OASIS3-MCT v4.0

Ho-Hagemann, Ha Thi Minh; Maurer, Vera; Poll, Stefan; Fast, Irina

doi:https://doi.org/10.5194/gmd-17-7815-2024

Articles | Volume 17, issue 21

https://doi.org/10.5194/gmd-17-7815-2024

© Author(s) 2024. This work is distributed under
the Creative Commons Attribution 4.0 License.

https://doi.org/10.5194/gmd-17-7815-2024

© Author(s) 2024. This work is distributed under
the Creative Commons Attribution 4.0 License.

Articles | Volume 17, issue 21

Model evaluation paper

|

07 Nov 2024

Model evaluation paper |

| 07 Nov 2024

Coupling the regional climate model ICON-CLM v2.6.6 to the Earth system model GCOAST-AHOI v2.0 using OASIS3-MCT v4.0

Ha Thi Minh Ho-Hagemann, Vera Maurer, Stefan Poll, and Irina Fast

Download

Final revised paper (published on 07 Nov 2024)
Supplement to the final revised paper
Preprint (discussion started on 26 Apr 2024)
Supplement to the preprint

Interactive discussion

Status: closed

CC1:
'Comment on egusphere-2024-923', Moritz Hanke, 06 May 2024

Hello,

You hopefully do not mind, if I give a few comments and remarks on your paper.
Disclaimer:

I am the main developer of YAC and I am involved in the development of the infrastructure in ICON.
General comments:

The paper gives the impression that with the introduction of OMCI, ICON is able to be coupled to external (non-ICON) components (see abstract or lines 407-409). However, in its current state, ICON is already able to do that. OMCI adds the possiblity to do this using OASIS3-MCT instead of YAC.
ICON consists of multiple components (e.g. atmosphere, ocean, and wave). The paper sometimes does not to distinguish between ICON and its components. It is also not clearly stated that OMCI supports the coupling of a single ICON component (ICON atmosphere) to an external one. Coupling between ICON components, or the coupling of multiple ICON components with an external one is not supported and potentially impossible due to how the initial communicator splitting is implemented.
Specific comments:

Line 49-50:

Can you elaborate why it is a major challenge to introduce a new coupling interface to NEMO and why this not the case for ICON?
Line 52:

Does the same argument for not having a need for a YAC interface in NEMO also applies to ICON?
Paragraph line 423-431:

Since ComIn does not allow a plugin to change the communicators of ICON, the current OMCI approach cannot be simply implemented as a ComIn-Plugin.

Citation: https://doi.org/10.5194/egusphere-2024-923-CC1
- AC1: 'Reply on CC1', Ha Ho-Hagemann, 05 Aug 2024
  
  Dear Moritz,
  Thanks a lot for your comments! Our answers are given below.
  >> The paper gives the impression that with the introduction of OMCI, ICON is able to be coupled to external (non-ICON) components (see abstract or lines 407-409). However, in its current state, ICON is already able to do that. OMCI adds the possibility to do this using OASIS3-MCT instead of YAC.
  We rewrite the sentence L.490-493:
  “The new OASIS3-MCT coupling interface OMCI implemented in the ICON-CLM model adds a possibility to couple ICON-CLM with an external ocean model and an external hydrological discharge model, not only with NEMO and HD, using OASIS3-MCT instead of YAC.”
  And modify the abstract:
  “The new OASIS3-MCT coupling interface OMCI implemented in the ICON-CLM model adds a possibility to couple ICON-CLM with an external ocean model and an external hydrological discharge model using OASIS3-MCT instead of the YAC coupler. Using OMCI, it is also possible to set up a RESM with ICON-CLM and other ocean and hydrology models possessing the OASIS3-MCT interface for other regions, such as the Mediterranean Sea.”
  
  >> ICON consists of multiple components (e.g. atmosphere, ocean, and wave). The paper sometimes does not to distinguish between ICON and its components. It is also not clearly stated that OMCI supports the coupling of a single ICON component (ICON atmosphere) to an external one. Coupling between ICON components, or the coupling of multiple ICON components with an external one is not supported and potentially impossible due to how the initial communicator splitting is implemented.
  We rewrite the introduction section to distinguish between the ICON components. In addition, “ICON-CLM” in the title refers to the atmospheric component of ICON.
  
  Specific comments:
  >> Line 49-50: Can you elaborate why it is a major challenge to introduce a new coupling interface to NEMO and why this not the case for ICON?
  We rewrite the paragraph as follows:
  L.61-74:
  “For the coupling of ICON-CLM as an atmosphere component into GCOAST-AHOI, which includes HD and the ocean model NEMO (Nucleus for European Modelling of the Ocean, Madec et al. 2017), representing the ocean and sea ice components, basically, there were two feasible options: either to implement a YAC interface in NEMO and HD, or to implement an OASIS interface in ICON-CLM. For the option one, the YAC coupling interface was added into the HD source code by M. Hanke (DKRZ) (see Hagemann et al. 2023), but YAC has not yet been available in the NEMO source code. To our current knowledge, there is no RESM with NEMO using the YAC coupler. The NEMO model is already linked to the OASIS coupler, which has been used to couple NEMO with many other model components. Implementing the YAC interface in NEMO would require a larger effort, as the NEMO source code is much more complicated than the HD code. In addition, although the NEMO source code is freely available, we are ordinary users in the NEMO community, not members of the model development team. Therefore, implementing and especially maintaining the YAC interfaces in NEMO is a big challenge.”
  
  >> Line 52: Does the same argument for not having a need for a YAC interface in NEMO also applies to ICON?
  We remove the sentence and rewrite the paragraph. Please read above.
  
  >>Paragraph line 423-431: Since ComIn does not allow a plugin to change the communicators of ICON, the current OMCI approach cannot be simply implemented as a ComIn-Plugin.
  Thanks a lot for your comment and the information. We rewrite this paragraph:
  L.506-514:
  “Recently, the ICON Consortium has developed and released the Community Interface (ComIn) for the ICON model to allow ICON to be coupled with external model components. The main challenge for the external model component coupling is the initial splitting of MPI_COMM_WORLD, which is done in ICON by a grouping of the mpi communicators (MPI-handshake) (M. Hanke, pers. communication, 2024). There are about 40 ComIn entry points in the new release version of ICON. Using the ComIn entry points does not require any additional patching of the ICON source code. A coupling interface to an external model such as OMCI must be moved into a ComIn-plugin to connect to the entry points in the ICON source code. In addition, the communicator splitting using the MPI-handshake algorithm must be implemented in the NEMO and HD source code.”
  Best regards,
  Ha et al.
  
  Citation: https://doi.org/10.5194/egusphere-2024-923-AC1
RC1:
'Comment on egusphere-2024-923', Anonymous Referee #1, 10 May 2024

The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2024/egusphere-2024-923/egusphere-2024-923-RC1-supplement.pdf

Citation: https://doi.org/10.5194/egusphere-2024-923-RC1
- AC2: 'Reply on RC1', Ha Ho-Hagemann, 05 Aug 2024
  
  Thank you very much for the comments! Our answers are given in the pdf file below.
  
  Citation: https://doi.org/10.5194/egusphere-2024-923-AC2
RC2:
'Comment on egusphere-2024-923', Anonymous Referee #2, 08 Jul 2024
The manuscript by Ho-Hagemann et al., which regards the coupling of the regional climate atmospheric model ICON-LAM with the ocean model NEMO using OASIS3-MCT in a configuration for the Baltic Sea, North Sea and Northeast Atlantic Sea, is interesting, aligned with the trend topics of the journal and represents a value contribution for GMD. The presented results, based on the main climate variables for regional models, seem satisfactory, and the arguments invoked to explain the bias of the coupled model are reasonable. Besides, this is one of the first (if not the first) work on a regional coupled version of ICON-LAM with NEMO, that could help the regional community modellers of ICON and NEMO interested in regional coupled climate simulations.
I recommend this article for a publication on GMD, however some minor comments should be addressed.
General comments:
From line 190 to 198, the authors describe the three coupling techniques and, in the end, they chose the mixing strategy, where NEMO averages the LH and SH send by ICON (fluxes calculated based on tile approach) and LH and SH calculated using bulk formulae. As the authors cite, this approach was also employed by Ho-Hagemann et al. (2020). In Ho-Hagemann et al. (2020), about the coupling of CCLM with NEMO, it was said that the default coupling strategy based on flux exchange from the atmosphere lead to large biases on SST, and that’s why they preferred to use the average of fluxes from both models based on different turbulence parameterizations. Even if could be true that the analysis of the best coupling strategy could go beyond the scope of this paper and could be matter of further studies, it could be useful to see an evaluation analysis of the turbulent fluxes component at surface against observations or reanalysis.

The authors should also include an evaluation analysis for the hydrological discharge component, this is extremely important to close the balance of the freshwater. If the results are unsatisfactory, they should be highlighted as current model limitation and, maybe, as further model improvement in future works.

Minor comments:
I found the interface structure part (lines 104-180) and the profiling part of the model with the LUCIA tool (lines 246-279) too technical and verbose. These parts could be summarized in the main core of the paper, while all the technicalities, which are extremely useful for the developers and users of both community models and for the reproducibility of the study, could go in the supplement material.

Some of the figure results regarding the NEMO standalone biases are just described and bear the wording “not shown”, maybe also these figures could go in the supplement material? Even if these figures could not give any added value for the results, they could help to visualize the NEMO standalone biases.

From line 46 to 51, the authors describe why they chose to implement OASIS in ICON and not YAC in NEMO. Could they elaborate on why the implementation of YAC in NEMO is a major challenge than the implementation of OASIS in ICON? I think that, besides the different coupler architectures and implementation issues, the main driver of this decision has been lack of a regional version of the ICON-O component, currently under development as explained in the results.
Citation: https://doi.org/10.5194/egusphere-2024-923-RC2
- AC3: 'Reply on RC2', Ha Ho-Hagemann, 05 Aug 2024
  
  Thank you very much for the comments! Our answers are given in the pdf file below.
  
  Citation: https://doi.org/10.5194/egusphere-2024-923-AC3

Peer review completion

AR: Author's response | RR: Referee report | ED: Editor decision | EF: Editorial file upload

AR by Ha Ho-Hagemann on behalf of the Authors (05 Aug 2024) Author's response Author's tracked changes

EF by Sarah Buchmann (07 Aug 2024) Manuscript

ED: Publish subject to technical corrections (28 Aug 2024) by Sophie Valcke

Dear Author,

Thank you very much for the updated manuscript, which answers quite carefully the reviewers' remarks.

I have a comment on the ICON MPI-handshake section which reads "“Recently, the ICON Consortium has developed and released the Community Interface (ComIn) for the ICON model to allow ICON to be coupled with external model components. The main challenge for the external model component coupling is the initial splitting of MPI_COMM_WORLD, which is done in ICON by a grouping of the mpi communicators (MPI-handshake) (M. Hanke, pers. communication, 2024). There are about 40 ComIn entry points in the new release version of ICON. Using the ComIn entry points does not require any additional patching of the ICON source code. A coupling interface to an external model such as OMCI must be moved into a ComIn-plugin to connect to the entry points in the ICON source code. In addition, the communicator splitting using the MPI-handshake algorithm must be implemented in the NEMO and HD source code.” I would use the conditional tense for the last sentence, to express the fact that this should be considered as a possibility. The sentence would then read "A coupling interface to an external model such as OMCI would have to be moved into a ComIn-plugin to connect to the entry points in the ICON source code. In addition, the communicator splitting using the MPI-handshake algorithm would have to be implemented in the NEMO and HD source code.”

Also the reference for the OASIS3-MCT coupler should be "Craig A., Valcke S., Coquart L., 2017: Development and performance of a new version of the OASIS coupler, OASIS3-MCT_3.0, Geoscientific Model Development, 10, pp. 3297-3308, (doi: https://doi.org/10.5194/gmd-10-3297-2017)", not the Valcke 2015 one.

Thank you in advance for considering these remarks,
With best regards,
Sophie Valcke

Hide

AR by Ha Ho-Hagemann on behalf of the Authors (30 Aug 2024) Manuscript

Short summary

The regional Earth system model GCOAST-AHOI v2.0 that includes the regional climate model ICON-CLM coupled to the ocean model NEMO and the hydrological discharge model HD via the OASIS3-MCT coupler can be a useful tool for conducting long-term regional climate simulations over the EURO-CORDEX domain. The new OASIS3-MCT coupling interface implemented in ICON-CLM makes it more flexible for coupling to an external ocean model and an external hydrological discharge model.