the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Implementation of solar UV and energetic particle precipitation within the LINOZ scheme in ICON-ART
Abstract. We extended the Linearized ozone scheme –LINOZ in the ICON (ICOsahedral Nonhydrostatic) –ART (the extension for Aerosols and Reactive Trace gases) model system to include NOy formed by auroral and medium-energy electrons in the upper mesosphere and lower thermosphere, and the corresponding ozone loss, as well as changes in the rate of ozone formation due to the variability of the solar radiation in the ultraviolet wavelength range. This extension allows us to realistically represent variable solar and geomagnetic forcing in the middle atmosphere using a very simple ozone scheme. The LINOZ scheme is computationally very cheap compared to a full middle atmosphere chemistry scheme, yet provides realistic ozone fields consistent with the stratospheric circulation and temperatures, and can thus be used in climate models instead of prescribed ozone climatologies. To include the reactive nitrogen (NOy) produced by auroral and radiation belt electron precipitation in the upper mesosphere and lower thermosphere during polar winter, the so-called energetic particle precipitation indirect effect an upper boundary condition for NOy has been implemented into the simplified parameterization scheme of the N2O/NOy reactions. This parameterization, which uses the geomagnetic Ap index, is also recommended for chemistry-climate models in the CMIP6 experiments. With this extension, the model simulates realistic „tongues“ of NOy propagating downward in polar witner from the model top in the upper mesosphere into the mid-stratosphere with an amplitude that is modulated by geomagnetic activity. We then expanded the simplified ozone description used in the model by applying LINOZ version 3. The additional ozone tendency from NOy is included by applying the corresponding terms of the version 3 of LINOZ. This NOy, coupled as an additional term in the linearized ozone chemistry, led to significant ozone losses in the polar upper stratosphere in both hemispheres which is qualitatively in good agreement with ozone observations and model simulations with EPP-NOy and full stratospheric chemistry. In a subsequent step, the tabulated coefficients forming the basis of the LINOZ scheme were provided separately for solar maximum and solar minimum conditions. These coefficients were then interpolated to ICON- ART using the F10.7 index as a proxy for daily solar spectra (UV) variability to account for solar UV forcing. This solar UV forcing in the model led to changes in ozone in the tropical and mid-latitude stratosphere consistent with observed solar signals in stratospheric ozone.
- Preprint
(8018 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 23 Apr 2025)
-
CEC1: 'Comment on gmd-2024-227 - No compliance with the policy of the journal', Juan Antonio Añel, 13 Feb 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.htmlThere are two main outstanding issues with your manuscript. First, the site you have linked, Radar4KIT, is not a suitable repository for long-term archival and scientific publication. Therefore, please, store your assets in an acceptable repository from the ones listed in our policy.
Second, you have only provided a small set of fourteen ART files. However, you must provide all the code necessary to replicate your work, which means that you must publish and store the full ICON-ART model.
Therefore, please, publish your code 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. Note that if you do not fix this problem, we will have to reject your manuscript for publication in our journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/gmd-2024-227-CEC1 -
CC1: 'Reply on CEC1', Maryam Ramezani Ziarani, 03 Mar 2025
reply
Dear executive editor,
Thank you for your feedback. Please find our responses to your comments below:
Repository compliance;
Our code is hosted on Radar4KIT, an institutional repository with guaranteed long-term availability. During the initial review process, this was deemed compliant with GMD’s policy on code and data availability. We would appreciate further clarification regarding the specific concerns raised about its suitability so we can better understand whether additional steps are required. Please find the description of RADAR4KIT at:
https://www.bibliothek.kit.edu/english/radar-description.php
Full code requirement;
Publishing the full ICON-ART model presents significant challenges due to its licensing constraints and dependencies. Our ICON-ART version includes components that cannot be made openly accessible. As an alternative, we have provided the relevant components necessary to understand our study, which aligns with our initial understanding of GMD’s requirements. Given these constraints, we seek clarification on whether this approach remains acceptable or if alternative solutions can be considered.
Proposed solution and timeline;
To address these concerns, we are working on an alternative solution that involves downgrading ART to Open Source Release (OSR) 24.10, merging our latest version with this release, and re-running the experiments. However, this process is complex and is expected to take approximately one month from now, assuming the model runs smoothly.
As our manuscript was previously accepted as a preprint under the initial review, this recent change in requirements raises concerns about consistency in policy enforcement. We kindly ask for clarification on how best to proceed under these circumstances.
We appreciate your time and consideration and look forward to your guidance.
Best regards,
authorsCitation: https://doi.org/10.5194/gmd-2024-227-CC1 -
CEC2: 'Reply on CC1', Juan Antonio Añel, 25 Mar 2025
reply
Dear authors,
Some clarifications regarding your comment. First, Radar4KIT is not a repository acceptable for publication of code or data. It has never been. In some cases, Topical Editors make mistakes during their initial assessment of a manuscript, of simply overlook the necessary justification of some elements related to code and data. To avoid such cases, executive editors review all the manuscripts submitted to the journal, and when it is necessary (as it has happened to your manuscript) make the authors and the editor aware of shortcomings related to the compliance with the policy. This is the case for your manuscript. Therefore, there is not inconsistency in our policy, simply the request about the repository did not happen at submission time and is enforced now. That said, before submission, you should have read our policy carefully, and checked the acceptable repositories that we list. If you had done it correctly, you would have been aware that Radar4KIT is not included, and then you could have changed the assets to a repository in compliance with our policy before submitting the manuscript, avoiding all this annoyance.
Regarding your limitations to publish the ICON-ART code, we are aware of some limitations of your model when it comes to open science. However, we have to assess each case independently. If you want to ask for an exception to our policy, you need to provide us evidence that publishing some parts of the code is out of your control and forbidden by law or a license. We would thank if you can provide us documentation or more information on it. Regarding the parts that you can publish, we expect that you do it in one of the acceptable repositories listed in our policy.
I hope this addresses your concerns and helps to clarify the situation.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/gmd-2024-227-CEC2 -
CC2: 'Reply on CEC2', Miriam Sinnhuber, 25 Mar 2025
reply
Dear Dr. Anel,
In reading your reply of today, we are left with the impression that GMD feels that Radar4KIT is not an acceptable repository for publication of code or data. We cannot understand why this is so.
1) Radar4KIT is a repository which enables publication of data with a doi and enables permanent and unaltered storage with at least 25 years guaranteed, as described on their website: https://www.bibliothek.kit.edu/english/radar-description.php. The guaranteed time of storage has been extended to 25 years recently, and this is now also clearly stated on the radar description.
2) The requirements stated by GMD (https://www.geoscientific-model-development.net/policies/code_and_data_policy.html) for suitable repositories explicitly ask for repositories with long-term unaltered storage and publication via a doi, criteria which Radar4KIT in our view clearly fulfills.
3) On the GMD submission page (https://www.geoscientific-model-development.net/submission.html) a link to suitable repositories is provided (https://www.re3data.org/), and Radar4KIT is listed there.
Kind regards,
Miriam Sinnhuber
Citation: https://doi.org/10.5194/gmd-2024-227-CC2 -
CEC3: 'Reply on CC2', Juan Antonio Añel, 26 Mar 2025
reply
Dear authors,
There are problems with Radar4KIT that make it unsuitable for permanent publication of the assets necessary to assure the replicability of a research paper, present and future, and therefore comply with the principles of the scientific method. This is independent of the fact that it has been included in one of the list that we cite for general reference.
Also, we have assessed Radar4KIT recently, and it was not in compliance with our requirements. However, as you insist in challenging our decision, I am explaining here the reasons.
The main problems are two.
1) The service provided by Radar4KIT says "The data provider can create data packages within the workspace assigned to him and assign individual files or ZIP files with several contained files to them, which he transfers to RADAR4KIT via the Internet. He can add or delete individual data via the user interface or the REST API." This makes clear that the author (data provider) can delete deposited data. We can not accept this. Acceptable repositories can not allow that authors remove data after depositing it.
2) In the same paragraph of the conditions for holding periods, that you mention to be up to 25 years, it reads: "The actual retention period for archived data packages may be shorter if the RADAR4KIT service is discontinued before the end of the retention period". We can not accept this. From this sentence it is clear that they exist doubts about the period for which the Radar4KIT service could be operative.
3) The policy regarding "Assignment of access rights and embargoes" mentions the possibility to modify access permissions after depositing the data. This is not acceptable. All the data must be published and without possibility to change initial conditions for access after it is published.
Anyone of these issues by itself would be enough to consider Radar4KIT not suitable to store the assets necessary to replicate a paper, and therefore scientific publication. Also, it is clear that they exist other options that provide a service that comply with our requirements. Therefore, there is no reason in this case that justify using a service that provides lower standards.
Please, store the assets requested in one of the acceptable repositories listed in our policy. Zenodo, PANGAEA or FigShare are good options.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/gmd-2024-227-CEC3 -
CC3: 'Reply on CEC3', Thomas Reddmann, 26 Mar 2025
reply
Dear Juan Añel,
I was a bit alarmed by your comment as I already published in EGU journals using radar4kit as a repository.
But inspecting the terms (https://www.bibliothek.kit.edu/english/radar-description.php#Anker7), it seems not to be so much different to Zenodo, for example:
"RADAR4KIT enables the permanent and unaltered storage of data packages for a defined period of time ("retention period"). .... For published data, an actual retention period of at least 25 years is guaranteed. ....
Data packages in permanent memory cannot be changed. In justified exceptional cases, data packages can be blocked by the administrator. Justified exceptional cases include, for example, legal violations or incorrect data. In case of a block access to the uploaded data is blocked, but not the descriptive metadata. These contain an indication that the data has been blocked."
and here an excerpt from Zenodo's terms:
"6. CERN reserves the right, without notice, at its sole discretion and without liability, (i) to alter, delete or block access to content that it deems to be inappropriate or insufficiently protected, and (ii) to restrict or remove User access where it considers that use of Zenodo interferes with its operations or violates these Terms of Use or applicable laws."
and from https://about.zenodo.org/policies/
"Retention period: Items will be retained for the lifetime of the repository. This is currently the lifetime of the host laboratory CERN, which currently has an experimental programme defined for the next 20 years at least."
That is, there is no real guarantee.
I think it is good that we have several services at hand for open publication in science and we as scientists should strengthen the institutions offering these services. If some clarification in the terms of use is helpful I hope, EGU and the resepctive service institutions are in good and constructive contact for further improvements.Hopefully, this may relax a bit the situation.Many greetings, Thomas ReddmannCitation: https://doi.org/10.5194/gmd-2024-227-CC3 -
CC4: 'Reply on CEC3', Karin Simianer, 27 Mar 2025
reply
Dear Juan Añel,
my name is Karin Simianer and I am speaking here as one of the RADAR4KIT administrators at KIT and
in consultation with the RADAR support team:I think that your assessment of RADAR4KIT as a repository not suitable for long-term archiving is
simply based on a misunderstanding between published and only archived data packages.In RADAR4KIT, a distinction is made between precisely these two options: you can archive data (and
not publish it) or publish it and make it freely accessible worldwide on a permanent basis: In the
current RADAR4KIT description (https://www.bibliothek.kit.edu/english/radar-description.php) it reads: „Once the compilation of a data package and its description
with metadata is complete, the curator can choose between two options: archiving or publication of
the research data.“Regarding the 3 problems you mentioned:
1) The text you quoted refers to the data transfer process. It describes the way in which data can be
transferred to RADAR4KIT. Of course, customers can delete the uploaded files BEFORE publication
and replace them with new ones if necessary. It would be a poor service if this were not possible and
serves the user-friendliness of the service during the processing status of the data packages.Once the data has been published or only archived, no further changes are possible. This is stated in
the description (see “Temporary Storage” https://www.bibliothek.kit.edu/english/radar-description.php#Anker5):„In the case of archiving or publication, the data packages move from temporary storage to
permanent storage.”and in the section “Holding periods and immutability of data packages” (https://www.bibliothek.kit.edu/english/radar-description.php#Anker7): “Data packages in
permanent memory cannot be changed. In justified exceptional cases, data packages can be blocked
by the administrator. Justified exceptional cases include, for example, legal violations or incorrect
data. In case of a block access to the uploaded data is blocked, but not the descriptive metadata.
These contain an indication that the data has been blocked.”2) The sentence “The actual retention period for archived data packages may be shorter if the
RADAR4KIT service is discontinued before the end of the retention period” refers only to archived
data. It says nothing about published data. In context it says:„RADAR4KIT enables the permanent and unaltered storage of data packages for a defined period of
time ("retention period"). For archived data packages, the data provider specifies a retention period.
The actual retention period for archived data packages may be shorter if the RADAR4KIT service is
discontinued before the end of the retention period. There is no need to select a retention period
for published data packages, it is in principle unlimited. The KIT guarantees an actual retention
period of at least 10 years for archived data. For published data, an actual retention period of at
least 25 years is guaranteed.“3) Here too, different options apply to archived data than to published data.
For published data an embargo period can be assigned and this can of course be shortened or
extended if necessary. This change option only applies to the embargo period: “The selected
embargo periods can also be changed, i.e. extended or shortened, by the data provider after
publication.” If the data was published without an embargo period, its availability cannot be
subsequently restricted - except in the case of justified exceptional cases, in which case the data
package can be blocked (see above).The mentioned possibility to modify access permissions after depositing the data only refers to
archived data.Even in case your objection refers to the license of the data package, we can assure you: once a
license has been selected for published (and archived) data, it cannot be changed at a later time thus
the conditions for re-use always remain the same.We can therefore assure you that RADAR4KIT is very well suited for permanent publication.
Kind regards, Karin Simianer
Karin Simianer
Karlsruher Institut für Technologie (KIT)
KIT-Bibliothek
Publikations- und Mediendienste / Team Repository KITopen
Straße am Forum 2, Geb. 30.50/30.51
76131 Karlsruhe
Tel.: +49 (0) 721/ 608-46722
Fax: +49 (0) 721/ 608-44886
E-Mail: openscience@bibliothek.kit.edu
Web: www.bibliothek.kit.eduCitation: https://doi.org/10.5194/gmd-2024-227-CC4
-
CC3: 'Reply on CEC3', Thomas Reddmann, 26 Mar 2025
reply
-
CEC3: 'Reply on CC2', Juan Antonio Añel, 26 Mar 2025
reply
-
CC2: 'Reply on CEC2', Miriam Sinnhuber, 25 Mar 2025
reply
-
CEC2: 'Reply on CC1', Juan Antonio Añel, 25 Mar 2025
reply
-
CC1: 'Reply on CEC1', Maryam Ramezani Ziarani, 03 Mar 2025
reply
-
RC1: 'Comment on gmd-2024-227', Anonymous Referee #1, 23 Mar 2025
reply
The comment was uploaded in the form of a supplement: https://gmd.copernicus.org/preprints/gmd-2024-227/gmd-2024-227-RC1-supplement.pdf
Viewed
HTML | XML | Total | BibTeX | EndNote | |
---|---|---|---|---|---|
270 | 38 | 14 | 322 | 10 | 8 |
- HTML: 270
- PDF: 38
- XML: 14
- Total: 322
- BibTeX: 10
- EndNote: 8
Viewed (geographical distribution)
Country | # | Views | % |
---|
Total: | 0 |
HTML: | 0 |
PDF: | 0 |
XML: | 0 |
- 1