the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Simulated and Observed Transport Estimates Across the Overturning in the Subpolar North Atlantic Program (OSNAP) Section
Abstract. A comparison of simulated and observed overturning transports and related properties across the Overturning in the Subpolar North Atlantic Program (OSNAP) sections for the 2014–2022 period is presented, considering both depth and density space transports. The effort was motivated by the observational transport estimates at both OSNAP-West (OW) and OSNAP-East (OE) sections which show a minor role for the Labrador Sea (LS) in setting the mean and variability of the overturning in the subpolar North Atlantic. There are 9 participating groups from around the world, contributing a total of 18 ocean – sea simulations with 6 different ocean models. The simulations use a common set of interannually-varying atmospheric forcing datasets. The horizontal resolutions of the simulations range from nominal 1° to eddy-resolving resolutions of 0.1°–0.05°. While there are many differences between the simulations and observations as well as among the individual simulations in terms of transport properties, the simulations show significantly larger transports at OE than at OW in general agreement with the observations. Analyzing overturning circulations in both depth and density space together provides a more complete picture of the overturning properties and features. This analysis also reveals that, in both the simulations and observations, northward and southward flows substantially cancel each other, producing much smaller residual (total) transports. Such cancellations tend to be much more prominent in depth space than in density space. In general, the observed transport features are captured better at OE than OW. The simulations generally show larger (smaller) transports with positive (negative) temperature and salinity biases in the upper ocean near the OSNAP sections, but with no such relationship with density biases. In high-resolution simulations, the transport profiles agree better with the observations in general, but challenges remain in some other metrics considered in our analysis. When transports are calculated using a density referenced to 2000-m depth, rather than the ocean surface, the relative contributions of transports at OW increase modestly.
- Preprint
(15728 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 07 Jan 2026)
- CC1: 'Comment on egusphere-2025-5406', Alexander Shchepetkin, 14 Nov 2025 reply
-
CEC1: 'Comment on egusphere-2025-5406 - No compliance with the policy of the journal', Juan Antonio Añel, 07 Dec 2025
reply
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.htmlYou have archived your code on GitHub. However, GitHub is not a suitable repository for scientific publication. GitHub itself instructs authors to use other long-term archival and publishing alternatives, such as Zenodo. Also, for the datasets used in your manuscript, you have not stored them in appropriate repositories, but simply provide links to sites that do not comply with the requirements of our policy. Therefore, the current situation with your manuscript is irregular, as it should have never been accepted for Discussions or send out for peer-review given such lack of compliance.
Please, 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, as we can not accept manuscripts in Discussions that do not comply with our policy.
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 our journal.
Juan A. Añel
Geosci. Model Dev. Executive EditorCitation: https://doi.org/10.5194/egusphere-2025-5406-CEC1 -
AC1: 'Reply on CEC1', Gokhan Danabasoglu, 09 Dec 2025
reply
Dear Juan,
Thank you for your comment. First, we would like to assure you that it is our intention to comply with the journal’s code and data policy fully.
We now have a DOI for METRIC on Zenodo at https://doi.org/10.5281/zenodo.17858479. This will be included in the manuscript.
The python code for the TEOS-10 Equation of State is not ours. Therefore, we followed the citation instructions provided by the developers of the code which asks the users to site McDougall and Barker (2011) as we have done here. We note that there is no DOI for this package, but we provided the relevant website at https://github.com/TEOS-10/GSW-Python. This repository contains useful information about TEOS-10 (Thermodynamic Equation of Seawater - 2010), the international standard for the description of the thermodynamic properties of seawater. Because this widely used software package is not ours, we do not think that it is up to us to provide a DOI for it.
We are a bit confused by your comments about the datasets as we thought we followed the guidelines as well as what has been done in manuscripts published in GMD. The guidelines state that “ ….. data as developed in the paper must be archived.” Following this guidance, all the simulation datasets used in our analysis region had been made already available at https://doi.org/10.5281/zenodo.17858479 in compliance with the GMD’s data policy. We note that the entire global datasets for the full integration lengths are too large (several hundreds of terabytes) to be archived on Zenodo. While these full datasets are not used in our analysis, we had provided additional information regarding from where some of these datasets could be accessed, including the Earth System Grid Federation (ESGF) and institutional repositories. Again, this is compliant with the GMD’s data policy which allows this information as long as the actual data used in our analysis are made available. Our intention here was simply to help the readers who may want to use these simulations for other analysis. We can certainly delete this additional information. Again, all the data needed to reproduce the analysis presented in our manuscript have been available at https://doi.org/10.5281/zenodo.17858479.
We finally note that the OSNAP observations are available at Georgia Tech Digital Repository at https://doi.org/10.35090/gatech/78023.
Please let us know if our understanding of and compliance with the GMD’s code and data policy need further changes.
Best,
Gokhan Danabasoglu and Fred Castruccio
Citation: https://doi.org/10.5194/egusphere-2025-5406-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 10 Dec 2025
reply
Dear authors,
Regarding the code for the TEOS-10 equation, it does not matter at all that you are not the developers. Such code is in GitHub under a BSD license, and therefore, you have the right to copy and redistribute it, provided you retain the same license. Therefore, please, proceed to create a repository that we can accept to store it, and reply to this comment with the information for it.
Regarding the OSNAP observations, as we can not accept the Georgia Tech Library to store the assets, and the dataset is under the US Copyright law, please, store it in Zenodo private repository. In this way you comply with the restrictions for distribution, and at the same time we are sure that the dataset is securely stored.
Regarding the outputs from models, we do not need that you store full output files, but the exact data you use, the variables for the specific region. It is unclear if this is what you mean by "The simulation datasets for our analysis region", please, clarify it. If the Zenodo repository for the mentioned analysis region does not contain all of the data, you could add it. Probably the size needed to store the specific data that you use is not of several Terabytes.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-5406-CEC2 -
AC2: 'Reply on CEC2', Gokhan Danabasoglu, 12 Dec 2025
reply
Dear Juan,
Thank you for your second comment.
Regarding the outputs from models, we had indicated that “all the data needed to produce the analysis presented in our manuscript have been available at https://doi.org/10.5281/zenodo.17858479” in the last sentence of the related paragraph in our previous reply. So, we believe that we had been clear and compliant with the GMD data policy.
Regarding OSNAP data and TEOS-10 software packages, we believe that there are moral and ethical considerations that are not reflected in the GMD policies. While acknowledging what is permissible under licensing agreements and providing a DOI does not imply ownership of a dataset or software, as a community we should abide by certain standards, considerations, and principles beyond just binary policy implications. With this background, we have reached out to the leaders of OSNAP and TEOS-10 efforts, seeking their guidance. Both groups indicated to us that we need to follow their recommended citation protocols and not create any duplicate DOI or duplicate code repositories. Please see the respective specifics below.
For OSNAP, the program website provides clear guidance on how to cite the data (https://www.o-snap.org/data-access/), including an official and permanent DOI (https://doi.org/10.35090/gatech/78023). The data are freely available and can be downloaded directly from that link.
For TEOS-10, we have been reminded by the leads of the project that:
“On 1st January 2010 TEOS-10 became the global standard for what seawater is, what to evaluate its thermodynamic properties, and how to measure it.”
“Since TEOS-10 is the global definition of seawater, if a reference is needed, then a reference to the TEOS-10 Manual, or Getting Started, or to the TEOS-10 web site is sufficient.”
“IOC, SCOR, IAPSO and IUGG all officially blessed TEOS-10 in 2009 and 2010, and they did not bless any DOI sites. The officially blessed things are the TEOS-10 Manual, the Getting Started document, and the software on the TEOS-10 software web page. That is all. Nothing else has received a blessing, so nothing else is actually TEOS-10.”
Furthermore:
“This [the TEOS-10 website] site is the official source of information about the Thermodynamic Equation Of Seawater - 2010 (TEOS-10), and the way in which it should be used.”
So, any DOI creation would go against the official OSNAP and TEOS-10 policies which are aimed at preventing proliferation of TEOS-10 packages which also defeats the purpose of DOIs as unique identifiers. Please also note that how to cite and where to store these datasets and packages are under the governance of various international bodies and projects, including their non-duplication at other sites.
Following this input and your comments, we also searched EGU publications, including those in GMD, regarding how they have cited both OSNAP and TEOS-10. Many manuscripts use these, especially TEOS-10, but none seems to have a DOI on Zenodo for these. We just provide three recent examples here:
Mignac et al. (2025, GMD, doi: 10.5194/gmd-18-3405-2025) cites the OSNAP website as the data source.
Couplet et al. (2025, GMD, doi: 10.5194/gmd-18-3081-2025) uses the same TEOS-10 packages, but they do not include them in their code availability section. They cite McDougall and Barker (2011) following the TEOS-10 guidelines.
Allende et al. (2024, GMD, doi: 10.5194/gmd-17-7445-2024) uses the TEOS-10 packages, but they do not include them in their code availability section. They cite McDougall and Barker (2011) following the TEOS-10 guidelines.
Indeed, there are other manuscripts in GMD with the same citation approaches as in the above examples.
In our case, we wanted to be as transparent as possible and included this information in the code availability section of our manuscript which appears to be not consistent with what is being done in other GMD publications. Perhaps this was our mistake.
So, your comments and requests are putting us between a rock and a hard place, considering community moral and ethical implications and existing precedence in published manuscripts in GMD. Again, noting that what you are asking might be perfectly fine legally, but it makes us rather uncomfortable and goes against the citation protocols laid down by the data and code creators and approved by the international decision makers.
In light of the above considerations and given the existing precedence in published manuscripts in GMD, we hope that you will agree that the official OSNAP DOI is an acceptable way to acknowledge and cite the OSNAP data in GMD. For TEOS-10 the precedence set in GMD seems to be not to include any TEOS-10 information in the code availability section. We propose to remove the link to the GitHub repository from the “code and data availability” and add the link to the official TEOS-10 website (https://www.teos-10.org/) in the main text along with the McDougall and Barker (2011) reference as requested by the GSW Oceanographic Toolbox developers. Again, please note that the TEOS-10 website (https://www.teos-10.org/) is the main sanctioned source of information about TEOS-10 and the way in which it should be used. It includes links to download the various official TEOS-10 software packages, including the python version we relied on for our analysis, and instructions on how to use those packages. It is by far the best source of information for anyone who wants to use TEOS-10.
Just as you are, our aim is to be fully transparent and provide all the datasets and software packages used in our study. We have accomplished this in our manuscript, also considering ocean science and modeling communities’ guidelines. After all, we are all in science together as a community.
Best,
Gokhan Danabasoglu and Fred Castruccio
Citation: https://doi.org/10.5194/egusphere-2025-5406-AC2 -
CEC3: 'Reply on AC2', Juan Antonio Añel, 12 Dec 2025
reply
Dear authors,
I appreaciate your reflection. However, what is wrong are these ill-perceived "ethical" or "moral" rules, which actually have nothing to do with ethics or moral. It is not unethical to copy and redistribute something for which the authors themselves have granted the permission in the license. GMD has a policy, and we are obligated to comply with it. The fact that other authors in the past, or published papers, have failed to comply with the requirements of the journal, whatever the reason, it does not justify non-compliance in this case. Therefore, we must insist that you comply with the requirements and store the required items in a repository acceptable according to the journal's policy.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-5406-CEC3
-
CEC3: 'Reply on AC2', Juan Antonio Añel, 12 Dec 2025
reply
-
AC2: 'Reply on CEC2', Gokhan Danabasoglu, 12 Dec 2025
reply
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 10 Dec 2025
reply
-
AC1: 'Reply on CEC1', Gokhan Danabasoglu, 09 Dec 2025
reply
-
CC2: 'Comment on egusphere-2025-5406', Stephen Griffies, 14 Dec 2025
reply
I have followed this exchange concerning the DOI for the OSNAP data and TEOS-10 code.
Both OSNAP and TEOS-10 are well established and sanctioned international projects. So long as the authors provide the specific links to the data and code, along with any necessary versioning information, that is sufficient for any interested reader to know precisely what was used, thus serving the ideals of open and reproducible research. Asking authors to, also, copy OSNAP and TEOS-10 onto their own Zenodo site with a DOI will proliferate data/software in a manner that is not sanctioned by those who developed the observations or software.
I agree that there is nothing illegal with producing a DOI of someone else's work, so long as the work has proper copyrights. But the question is whether doing so serves the ideals of open and reproducible science in a manner that does not present any perception of spuriously moving ownership. In my assessment, it confuses and so does not serve the ideals of open research.
Although it is quite possible I am missing something, this particular case seems to be one where remaining strict to the verbiage of a journal's rule leads to obfuscation and potential for confusion. I thus support what the authors propose.
I offer one somewhat related example.
Citation: https://doi.org/10.5194/egusphere-2025-5406-CC2 -
CC3: 'Comment on egusphere-2025-5406', Trevor McDougall, 15 Dec 2025
reply
I strongly discourage the proliferation of the TEOS-10 source code. That is, the TEOS-10 algorithms SHOULD NOT be reproduced in a DOI. TEOS-10 is the officially adopted description of Seawater, Ice-Ih and humid air. It has been endorsed by IAPSO, SCOR, IAPWS and IUGG, the four key relevant international bodies, and formally adopted by the Intergovernmental Oceanographic Commission at it Assembly in mid 2009 after every country of the United Nations was asked to comment on the draft TEOS-10 release documents. TEOS-10 became the internationally endorsed definition of seawater on 1st January 2010. I chaired the Working Group 127 of SCOR/IAPSO that developed TEOS-10.
When TEOS-10 was announced to the world there were official announcements in several oceanographic journals recommending how its adoption should proceed. An important aspect of these announcements was that the computer algorithms of TEOS-10 should be sourced from one location, namely from the web page https://www.teos-10.org/software.htm . The point of this recommendation is to reduce the possibility of incorrect code infiltrating the community. This is the recommendation of the Intergovernmental Oceanographic Commission (IOC).
I have published a paper in GMD that used TEOS-10 and was not asked to duplicate the TEOS-10 computer code, see https://gmd.copernicus.org/articles/14/6445/2021/gmd-14-6445-2021.pdf . There are thousands of papers that have been published in many journals (including journals in the Copernicus stable, such as Ocean Science) that have not included a DOI that duplicates the code of TEOS-10. For example, there are 1,500 citations to the Getting Started book, https://www.teos-10.org/pubs/gsw/v3_04/pdf/Getting_Started.pdf , but as far as I am aware, none of these papers have duplicated the TEOS-10 code. Duplicating this code is a risky practice and is not recommended.
Here is one of the announcements of TEOS-10, published in Deep-Sea Research https://www.teos-10.org/pubs/Announcement_Deep_Sea_Research.pdf .
Citation: https://doi.org/10.5194/egusphere-2025-5406-CC3 -
CEC6: 'Citations and code archival', David Ham, 22 Dec 2025
reply
It is important to distinguish here between giving proper credit to the TEOS-10 algorithm, by citing MacDougall and Barker (2011) and identifying the precise version of code used in this paper. Neither citing that paper nor referencing https://www.teos-10.org/software.htm can do that. If it is the preferred practice in the relevant community that that paper is the definitive citation and that that is the preferred download location then of course both of those things should appear in the paper.The issue here is that this is not sufficient for the reader to understand exactly which version of which software was used. Even a reference to the git repository in question, which is only one of a number of different implementations of TEOS-10 presented on the website, does not identify the particular version used. Further, GitHub is not a suitable archive location. I note, for example that, that development of the GSW-Python package has only been in that Git repository since 2017, much more recently than 2011, and that development could move elsewhere if, for example, GitHub change their policies in a manner inconvenient for the project. Git commit hashes can also become invalid if the project history is rewritten, for example to remove code included in breach of copyright.It is for this reason that GitHub themselves publish a mechanism for making citable archived copies of particular versions of repositories on Zenodo (https://docs.github.com/en/repositories/archiving-a-github-repository/referencing-and-citing-content#issuing-a-persistent-identifier-for-your-repository-with-zenodo).It is apparent that the authors of GSW-Python are aware of the GitHub-Zenodo linkage, because they have used it (Firing et al. 2021). It is surprising to hear that there is felt to be an in-principle objection to an archival mechanism that the authors themselves have used and, indeed link to from the README file in their own repository (https://github.com/TEOS-10/GSW-Python/blob/main/README.md). Indeed, if anything the somewhat problematic issue here is that by not issuing Zenodo records for releases since 2021 the package authors may induce a user to cite the wrong version of their software.Prof. McDougall’s objection to using this mechanism is that creating copies of the software violates the principle of single source of truth. However, computers work by copying. Avoiding copies, even publicly accessible copies, of open source software is simply impossible. Indeed, it is straightforward to find several sources of the code in question:
-
The Conda package (https://anaconda.org/channels/conda-forge/packages/gsw/overview) which is published by the package authors and listed as the preferred installation route on the TEOS website.
-
The Python package on PyPI (https://pypi.org/project/gsw/), likewise published by the package authors.
-
The Ubuntu package (https://launchpad.net/ubuntu/+source/gsw) packaged by the Debian Science team.
-
The Fedora package (https://packages.fedoraproject.org/pkgs/python-gsw/python3-gsw/) maintained by the pseudonymous qulogic.
-
34 Forks of the GitHub package.
-
Public proliferation of copies is normal and inevitable for this sort of important open-source software. It is instead the traceability of copies that ensures that single source of truth is maintained.What is being asked for here is that a reference is provided to a persistent copy of the exact version used in this work. If this is done via Zenodo then this can refer directly back to the current version of the software on GitHub, as all the routes above do. Further, this is something that the package authors have done in the past. In the light of the above, I am at a loss to understand why this is considered problematic.As the latter 3 examples illustrate, there isn’t really a distinction between this archiving being done by the package authors or by a third party such as the paper authors. The examples further illustrate that there is no convention or practice that third parties do not publish copies of this sort of software.Finally, I note that several comments indicate that previous papers have been published without a precise citation, including in GMD. This simply reflects that publishing full provenance information for geoscientific modelling papers is an evolving process. Over time we have got better at understanding what can and should be done, and the effectiveness of enforcement of the policies and principles has improved. That sometimes means that past practice is no longer considered best practice today.My understanding of the best practice in this situation would be for the precise version of the software to be archived in a long-term archive and referred to via a persistent identifier such as a DOI. This appears to me straightforward and not in conflict with the past practice surrounding this package.ReferencesEric Firing, Filipe, Andrew Barna, & Ryan Abernathey. (2021). TEOS-10/GSW-Python: v3.4.1.post0 (v3.4.1.post0). Zenodo. https://doi.org/10.5281/zenodo.5214122McDougall, T.J. and P.M. Barker, 2011: Getting started with TEOS-10 and the Gibbs Seawater (GSW) Oceanographic Toolbox, 28pp., SCOR/IAPSO WG127, ISBN 978-0-646-55621-5.Citation: https://doi.org/10.5194/egusphere-2025-5406-CEC6 -
-
CEC6: 'Citations and code archival', David Ham, 22 Dec 2025
reply
-
CC4: 'Comment on egusphere-2025-5406', Susan Lozier, 17 Dec 2025
reply
Speaking on behalf of the OSNAP International steering committee, I am opposed to any proliferation of DOIs for the OSNAP dataset for the same reasons that Trevor MacDougall has articulated for TEOS-10. The OSNAP data are publicly available and can be freely downloaded from the official DOI (https://doi.org/10.35090/gatech/78023). Any such reproduction is bound to cause confusion. To move forward, a clearer explanation of how the current DOI violates GMD policy would be helpful.
Citation: https://doi.org/10.5194/egusphere-2025-5406-CC4 -
CEC4: 'Reply on CC4', Juan Antonio Añel, 17 Dec 2025
reply
Dear authors,
The problem with storing assets in the Georgia Tech Library services has nothing to do with the DOI, but with the lack of a long-term preservation and data removal policy. We request evidence of funding secured or commitment to operate and preservation of the assets for, usually, 15-20 years, 10 years in some exceptional cases. Also, we request the existence of a clear policy where once the assets are deposited, it is ensured that they will not be removed except in exceptional cases (illegal content or similar) and that authors can not modify or delete the deposited content. Unfortunately, the Georgia Tech Library, to the best of our knowledge and given the documentation published, does not comply with the mentioned requirements.
However, I want to note that this is not the only outstanding issue with your manuscript. We refer you here to my previous comment, and ask you to address all the mentioned outstanding issues. For example, we can not accept GitHub to store your code, and despite any preferences you have regarding republication of code and data, all the manuscripts submitted to GMD must comply with the policy of the journal. Regarding your worries about republication, I should note that creating and publishing new copies of TEOS-10, is not under your control, as it is under the BSD license. Anyone can copy and publish it elsewhere. This need for ability for republication extends to mostly all the assets necessary to replicate a manuscript submitted to GMD, as a license that allows redistribution is necessary to be able to access and verify the code and data for a submitted manuscript.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-5406-CEC4 -
CEC5: 'Reply on CEC4', David Ham, 22 Dec 2025
reply
Dear all,
Having looked at the policies posted on the Georga Tech library repository, I can confirm that this is a suitable data repository and hence the archiving of this data is compliant with GMD policy. I will respond on the TEOS code issue separately.
Sincerely,
David
Citation: https://doi.org/10.5194/egusphere-2025-5406-CEC5
-
CEC5: 'Reply on CEC4', David Ham, 22 Dec 2025
reply
-
CEC4: 'Reply on CC4', Juan Antonio Añel, 17 Dec 2025
reply
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 481 | 116 | 45 | 642 | 15 | 15 |
- HTML: 481
- PDF: 116
- XML: 45
- Total: 642
- BibTeX: 15
- EndNote: 15
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Line 1416 "We use adaptive-implicit vertical advection (Shchepetkin & McWilliams, 2005)" incorrect citation.
Should be (Shchepetkin, 2015) instead, referring to
https://www.sciencedirect.com/science/article/pii/S1463500315000530
instead.