the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Meridional heat transport in the North Atlantic: Effects of ocean and atmosphere grid resolutions in FOCI-OpenIFS-AGRIF 3.0
Abstract. We present results of a new coupled climate model configurations named FOCI-OpenIFS-AGRIF 3.0. Advancing from the Flexible Ocean and Climate Infrastructure version 1 (FOCI1, Matthes et al., 2020), the new configuration employs the OpenIFS atmosphere model for improved computational scaling at high grid resolutions. Moreover, a novel coupling technique is developed to enable direct exchange of surface fluxes between an embedded zoom in the ocean model (AGRIF) and the atmosphere component through the coupler in addition to the coupling between the global atmosphere and global ocean. We discuss major differences between three configurations: one with low resolution in ocean (1/2◦, 25–50 km) and in atmosphere (∼100 km), one with the refined 1/10◦ (5–10 km) ocean grid in the North Atlantic but still low resolution atmosphere, and a third one with additionally globally enhanced atmosphere resolution at ∼31 km and 50% more vertical levels. The regionally eddy-rich ocean yields an improved North Atlantic Current path and enhanced northward volume and heat transport simulating a stronger subpolar gyre. Increasing the atmospheric resolution to better match the refined ocean grid yields larger winter heat loss over the subpolar North Atlantic thereby reducing the ocean heat transport into the Nordic Seas despite an unaltered volume transport compared to the configuration with only enhanced ocean resolution. We conclude that just increasing ocean grid resolution shifts meridional heat transport from the atmosphere to the ocean in the North Atlantic region. For a realistic balance between ocean and atmosphere transport matching grid resolutions are required to properly simulate heat exchange at subpolar latitudes.
- Preprint
(9946 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 21 Jul 2026)
-
CEC1: 'Comment on egusphere-2026-1481 - No compliance with the policy of the journal', Juan Antonio Añel, 21 Jun 2026
reply
-
AC1: 'Reply on CEC1', Sayantani Ojha, 29 Jun 2026
reply
Dear Dr. Juan A. Añel,
Thank you for your comment. We will clarify the availability of the model input data, source code, configuration files, and model output data in the revised manuscript. We will incorporate all the below mentioned details, including the corresponding links, in the revised version of the manuscript.The OpenIFS initial conditions are available at https://doi.org/10.5281/zenodo.20802457 (Kjellsson, J., 2026a). However, we are not allowed to share grid files and forcing files for OpenIFS and those must be requested directly from ECMWF. The CMIP6 forcing data, on the other hand, are publicly available through input4MIPs.
The full NEMO v3.6 source code as used here, is available at https://doi.org/10.5281/zenodo.20802615 (Wahl et al., 2026), and the corresponding input files used in this study can also be accessed from https://doi.org/10.5281/zenodo.20802303 (Kjellsson, J., & Wahl, S., 2026a). The XIOS source code and OASIS coupling files for FOCI-OpenIFS 3.0 AGRIF can be downloaded from https://doi.org/10.5281/zenodo.20802674 (Kjellsson, J., & Wahl, S., 2026b) and https://doi.org/10.5281/zenodo.20801841 (Kjellsson, J., 2026b) respectively. The configuration files for ORCA05-VIKING10 NEMO-AGRIF used in FOCI and FOCI-OpenIFS AGRIF are available at https://doi.org/10.5281/zenodo.20802421 (Martin, T., & Kjellsson, J., 2026).
The model output data required to reproduce the results presented in this publication are available at https://doi.org/10.5281/zenodo.20843398 (Ojha S. et al, 2026).
Citation: https://doi.org/10.5194/egusphere-2026-1481-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 29 Jun 2026
reply
Dear authors,
Thanks for your reply. Unfortunately, it does not satisfies the requirements made in my previous comment. You provide a repository for some OpenIFS data, but you must share the OpenIFS code, not the data. Also, you state that you are not allowed to redistribute some ECMWF data that you have used. To accept this we need evidence of what prevents you of sharing it, please, share it here. In such case, you must provide clear instructions on how to access them. To state that they must be obtained from the ECMWF is not enough.
Also, for the CMIP6 data you state "are publicly available through input4MIPs". This is not enough information. We can accept that some files are stored in the ESGF; however, you must provide clear information on how to access them, such as link and DOI, and identify the enembles and files used for your work.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-1481-CEC2
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 29 Jun 2026
reply
-
AC1: 'Reply on CEC1', Sayantani Ojha, 29 Jun 2026
reply
-
RC1: 'Comment on egusphere-2026-1481', Anonymous Referee #1, 23 Jun 2026
reply
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2026/egusphere-2026-1481/egusphere-2026-1481-RC1-supplement.pdf
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 98 | 31 | 10 | 139 | 10 | 14 |
- HTML: 98
- PDF: 31
- XML: 10
- Total: 139
- BibTeX: 10
- EndNote: 14
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.html
In the Code and Data Availability section of your manuscript you cite several sites that we can not accept as repositories for the assets necessary to replicate your work. First, you state " We do not have the possibility to make input and output data publicly available with a DOI. The original model simulation input and output files are stored at Kiel University and can be made available by the authors upon reasonable request." It is not clear at all what prevents you of making the input and output data available, and you must provide a better justification for it. Also, in the second sentence you state that the input and output files are available under "reasonable request". Those statements are not acceptable, and we request you to store the mentioned data in one of the repositories acceptable according to our policy, or to provide a good reasoning that prevents you of making the mentioned data available. In any case, the statement about "reasonable request" is not acceptable. Data must be provided to anyone that request them, and you should establish a method to ensure it.
To access XIOS you link a site hosted under jussieu.fr, which we can not accept. The same applies to the GitLab site linked and to the observations and reanalysis datasets. To access the OpenIFS version you link a ECMWF site, which we also cannot accept, and you must store the OpenIFS version used (something you can do, as it is under the Apache 2.0 license) in a repository we can accept. The mentioned sites that you have cited for all the mentioned assets do not fulfil GMD’s requirements for a persistent data archive because:
- They do not appear to have a published policy for data preservation over many years or decades (some flexibility exists over the precise length of preservation, but the policy must exist).
- They do not appear to have a published mechanism for preventing authors from unilaterally removing material. Archives must have a policy which makes removal of materials only possible in exceptional circumstances and subject to an independent curatorial decision,
- They do not appear to issue a persistent identifier such as a DOI or Handle for each precise dataset.
If we have missed a published policy which does in fact address this matter satisfactorily, please post a response linking to it. If you have any questions about this issue, please post them in a reply.
The GMD review and publication process depends on reviewers and community commentators being able to access, during the discussion phase, the code and data on which a manuscript depends, and on ensuring the provenance of replicability of the published papers for years after their publication. Please, therefore, publish your code and data in one of the appropriate repositories and reply to this comment with the relevant information (link and a permanent identifier for it (e.g. DOI)) as soon as possible. We cannot have manuscripts under discussion that do not comply with our policy.
Later, if the Topical Editor decides to continue with the review or publication process of your manuscript and you are requested to upload a new version of it, then The 'Code and Data Availability’ section of your manuscript must also be modified to cite the new repository locations, and corresponding references added to the bibliography.
I must note that if you do not fix this problem, we cannot continue with the peer-review process or accept your manuscript for publication in GMD.
Juan A. Añel
Geosci. Model Dev. Executive Editor