Implementation of solar UV and energetic particle precipitation within the LINOZ scheme in ICON-ART

Ramezani Ziarani, Maryam; Sinnhuber, Miriam; Reddmann, Thomas; Funke, Bernd; Bender, Stefan; Prather, Michael

doi:https://doi.org/10.5194/gmd-18-7891-2025

Articles | Volume 18, issue 20

https://doi.org/10.5194/gmd-18-7891-2025

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

https://doi.org/10.5194/gmd-18-7891-2025

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

Articles | Volume 18, issue 20

Development and technical paper

|

27 Oct 2025

Development and technical paper |

| 27 Oct 2025

Implementation of solar UV and energetic particle precipitation within the LINOZ scheme in ICON-ART

Maryam Ramezani Ziarani, Miriam Sinnhuber, Thomas Reddmann, Bernd Funke, Stefan Bender, and Michael Prather

Download

Final revised paper (published on 27 Oct 2025)
Preprint (discussion started on 23 Jan 2025)

Interactive discussion

Status: closed

CEC1:
'Comment on gmd-2024-227 - No compliance with the policy of the journal', Juan Antonio Añel, 13 Feb 2025

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
There 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
  
  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,
  
  authors
  
  Citation: https://doi.org/10.5194/gmd-2024-227-CC1
  - CEC2: 'Reply on CC1', Juan Antonio Añel, 25 Mar 2025
    
    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
    
    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
    
    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
    
    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 Reddmann
    
    Citation: https://doi.org/10.5194/gmd-2024-227-CC3
    
    CC4: 'Reply on CEC3', Karin Simianer, 27 Mar 2025
    
    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.edu
    
    Citation: https://doi.org/10.5194/gmd-2024-227-CC4
    
    CEC4: 'Reply on CC4', Juan Antonio Añel, 31 Mar 2025
    
    Dear authors and Karin Simianer,
    Many thanks for the explanations provided regarding Radar4KIT. After assessing the information we have decided that we can accept Radar4KIT as a suitable repository to store the code and data of manuscripts submitted to Geosci. Model Dev. Therefore, our new assessment is that the current version of this manuscript complies with the code and data policy of the journal, and no further action is necessary on it at the moment.
    As an additional note, I would like to point out that the description of the conditions and policies in the Radar4KIT webpage could benefit of more clear explanations that make clear the points we have discussed here. It would be good if you could include there the funding sources for the repository that make clear the willingness and funding supporting the mentioned 25 years storage period. Also, it would benefit of making clear that authors can not remove the data after depositing it, and if you have a committee to assess the cases where it is requested, clarifying their members.
    Juan A. Añel
    Geosci. Model Dev. Executive Editor
    
    Citation: https://doi.org/10.5194/gmd-2024-227-CEC4
RC1:
'Comment on gmd-2024-227', Anonymous Referee #1, 23 Mar 2025

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

Citation: https://doi.org/10.5194/gmd-2024-227-RC1
- CC5: 'Reply on RC1', Maryam Ramezani Ziarani, 28 Apr 2025
  
  Dear Reviewer, thank you very much for your positive and constructive comments. Please find our responses to your comments attached.
  
  Citation: https://doi.org/10.5194/gmd-2024-227-CC5
RC2:
'Comment on gmd-2024-227', Anonymous Referee #2, 11 May 2025

The manuscript describes a modification of the LINOZ chemical module to include the influence of NOy influx from the thermosphere on stratospheric ozone. The idea of using fast chemical solver is very attractive for the climate community because chemical modules usually deteriorate earth system model computational performance. I definitely support the idea, but the manuscript unfortunately does not provide complete description of the suggested LINOZ improvement. For GMD is not acceptable because it is virtually impossible to reproduce many introduced but not properly described modifications. I believe that the manuscript does not present satisfactory level of novelty and cannot recommend it for the publication. Some of manuscript problems are enlisted below.
Issues
Line 40: More frequent is underestimation.

Line 47: Via chemical reactions, but how about dynamical processes (Seppala et al., 2025, https://doi.org/10.1038/s41467-025-55966-z)?

Section 2.1: Too short. What about physical processes and so on…

Line 103: “ART coupler in a flexible way using meta-information within XML files”. What does it mean?

Section 2.2: Too short. What about transport, photolysis rates and so on?

Lines 126-128: The LINOZ description is too short. How are P and L terms calculated? What chemical species are used for this?

Line 131: Fixed H2O means that the impacts of solar variability on HOx production and, therefore, on ozone is missing. For the mesosphere it is a serious flaw.

Line 135: “it simplifies the model to highlight the solar-ozone interaction”. It simplifies for sure but does not highlight solar-ozone interaction due to absence of N2O response to O(1D) and photolysis.

Line 139: What is the model top?

Line 144: If the vertical transport is wrong, prescription of the NOy density will not help, because the downward transport from the upper layers is wrong.

Line 150: NOy in situ production in the mesosphere can be treated in the model,

Line 155: I do not understand what was done.

Section 3, last para. I think we should wait for these necessary steps before publication.

Line 164: 2.5-year spin-up time is too short.

Line 168-169: If the ozone is not used for radiation calculation, how can the solar influence be estimated?

Line 169: What does it mean “Polar chemistry was activated …”. The ozone layer is not prescribed then

Line 173: Three different scenarios (Stenchikov et al.,1998, 2004, 2009).I do not think 1998 work can be used for 2000-2010 run.

Lines 215-217: What does it mean? It is not understandable w/o missing detailed LINOZ description.

Lines 231-234: The explanation is too vague. How Brewer-Dobson circulation (Brewer, 1949) and mesospheric meridional circulation work. In the published papers we do not see robust polar ozone response to solar variability.

Figure 3: The figure is not visible due to overlapping with the legend. There is no doubt that NOy in ICON and EMAC are close because of similar set-up, but what it is not about LINOZ.

Section 5: Is it about EMAC comparison with ICON-ART or ICON-ART-LINOZ and? It is not clearly stated.

Figure 7: There is some agreement, but it is hard to say what the reason for it because the procedure was not clearly accepted. I am surprised that NOy alone (w/o HOx) gives such a strong response in the mesosphere. The ozone response (up to 30-50%) in the stratosphere looks overestimated. From the observations it should be less than 10%.

Figure 8: Hard to compare due to different axis. It is strange that there is no negative ozone response in the mesosphere. Is the Lyman-alpha line missing?

Citation: https://doi.org/10.5194/gmd-2024-227-RC2
- AC1: 'Reply on RC2', Maryam Ramezani Ziarani, 03 Jun 2025
  
  Please see our response letter in the attached PDF file.
  
  Citation: https://doi.org/10.5194/gmd-2024-227-AC1

Peer review completion

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

AR by Maryam Ramezani Ziarani on behalf of the Authors (25 Jul 2025) Author's response Author's tracked changes Manuscript

ED: Publish as is (11 Aug 2025) by Tatiana Egorova

AR by Maryam Ramezani Ziarani on behalf of the Authors (19 Aug 2025)

Short summary

Our study aims to present a new method for incorporating top-down solar forcing into stratospheric ozone relying on linearized ozone scheme. The addition of geomagnetic forcing led to significant ozone losses in the polar upper stratosphere of both hemispheres due to the catalytic cycles involving NO_y. In addition to the particle precipitation effect, accounting for solar UV variability in the ICON-ART model leads to the changes in ozone in the tropical stratosphere.