the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 26 Apr 2024
Coupling the regional climate model ICON-CLM v2.6.6 into the Earth system model GCOAST-AHOI v2.0 using OASIS3-MCT v4.0
Abstract. Interactions and feedback between compartments of the Earth system can have a significant impact on local and regional climate and its changes due to global warming. These effects can be better represented by regional Earth system models (RESMs) than by traditional stand-alone atmosphere and ocean models. Here, we present the RESM GCOAST-AHOI version 2.0, which includes a new atmospheric component, the regional climate model ICON-CLM, which is coupled with the ocean model NEMO and the hydrological discharge model HD via the OASIS3-MCT coupler. The GCOAST-AHOI model has been developed and applied for climate simulations over the EURO-CORDEX domain. Two 11-year simulations from 2008–2018 of the uncoupled ICON-CLM and GCOAST-AHOI give similar results for seasonal and annual means of near-surface air temperature, precipitation, mean sea level pressure and wind speed at 10 m height. However, GCOAST-AHOI has a cold SST bias of 1–2 degrees over the Baltic and the North Seas, most pronounced in winter and spring seasons. A possible reason for the cold SST bias could be the underestimation of the downward shortwave radiation at the surface of ICON with the current model settings. Despite of the cold SST bias, GCOAST-AHOI was able to capture other key variables such as those mentioned above well. Therefore, GCOAST-AHOI can be a useful tool to apply for long-term climate simulations over the EURO-CORDEX domain. The new OASIS3-MCT coupling interface OMCI implemented in the ICON-CLM model makes the ICON-CLM model more flexible to couple with an external ocean model and an external hydrological discharge model. Using OMCI, it is also possible to set up a RESM for other regions, such as the Mediterranean Sea.
-
Notice on discussion status
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
-
Preprint
(2947 KB)
-
Supplement
(2593 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(2947 KB) - Metadata XML
-
Supplement
(2593 KB) - BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this 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
-
AC1: 'Reply on CC1', Ha Ho-Hagemann, 05 Aug 2024
-
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
- AC2: 'Reply on RC1', Ha Ho-Hagemann, 05 Aug 2024
-
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
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
-
AC1: 'Reply on CC1', Ha Ho-Hagemann, 05 Aug 2024
-
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
- AC2: 'Reply on RC1', Ha Ho-Hagemann, 05 Aug 2024
-
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
Peer review completion
Journal article(s) based on this preprint
Data sets
Regional Earth system model GCOAST-AHOI v2.0 with ICON-CLM Ha Thi Minh Ho-Hagemann https://doi.org/10.5281/zenodo.11057794
Model code and software
Regional Earth system model GCOAST-AHOI v2.0 with ICON-CLM Ha Thi Minh Ho-Hagemann https://doi.org/10.5281/zenodo.11057794
Viewed
| HTML | XML | Total | Supplement | BibTeX | EndNote | |
|---|---|---|---|---|---|---|
| 372 | 127 | 144 | 643 | 49 | 23 | 26 |
- HTML: 372
- PDF: 127
- XML: 144
- Total: 643
- Supplement: 49
- BibTeX: 23
- EndNote: 26
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Ha Thi Minh Ho-Hagemann
Vera Maurer
Stefan Poll
Irina Fast
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(2947 KB) - Metadata XML
-
Supplement
(2593 KB) - BibTeX
- EndNote
- Final revised paper