the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 12 Dec 2024
Copernicus Atmosphere Monitoring Service – Regional Air Quality Production System v1.0
Abstract. The Copernicus Atmosphere Monitoring Service (CAMS) delivers a range of full, free and open products in relation to atmospheric composition at global and regional scales. The CAMS Regional Service produces daily forecasts, analyses, and reanalyses of air quality in Europe. This Service relies on a distributed modelling production by eleven teams in ten European countries: CHIMERE (France), DEHM (Denmark), EMEP (Norway), EURAD-IM (Germany), GEM-AQ (Poland), LOTOS-EUROS (The Netherlands), MATCH (Sweden), MINNI (Italy), MOCAGE (France), MONARCH (Spain), SILAM (Finland). The project management and coordination of the service is devoted to a Centralised Regional Production Unit. Each model produces every day 24 h analyses for the previous day and 97 h forecasts for 19 chemical species over a spatial domain at 0.1x01. degree resolution (approximately 10 km x 10 km) with 420 points in latitude and 700 in longitude and 10 vertical levels. Six pollen species are also delivered for the surface forecasts. The eleven individual models are then combined into an ENSEMBLE median. In total, more than 82 billion data points are made available for public use on a daily basis.
The design of the system follows clear technical requirements in terms of consistency in the model setup and forcing fields (meteorology, surface anthropogenic emission fluxes, and chemical boundary conditions). But it also benefits from a diversity of in the description of atmospheric processes through the design of the eleven European Chemistry Transport Models (CTM) involved.
The present article aims to provide a comprehensive technical documentation, both for the setup as well as for the diversity of CTM involved in the Service. We also include an overview of the main output products, their public dissemination and the related evaluation and quality control strategy.
- Preprint
(1780 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
-
CEC1: 'Comment on egusphere-2024-3744', Juan Antonio Añel, 27 Dec 2024
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.htmlIn your Code Availability section you fail to list suitable repositories for all the models that you use in your work. Some of them are institutional servers or Git sites that do not comply with the requirements necessary. For example, for the Chimere model you cite an institutional repository, when you could cite a Zenodo repository (as it exists for some Chimere versions). In other cases it is stated that the access to the code is open "upon request" or for "collaborative requests". We can not accept such limitations. All the code and data must be published openly and freely to anyone before submission of a manuscript.
Therefore, we are granting you a short time to solve this situation. You have to reply to this comment in a prompt manner with the information for the repositories containing all the models, code and data that you use to produce and replicate your manuscript. The reply must include the link and permanent identifier (e.g. DOI) for each mddel. Also, any future version of your manuscript must include the modified section with the new information.
Note that if you do not fix these problems as requested, we will have to reject your manuscript for publication in our journal. In the meantime I advice the Topical Editor to stall the peer-review process until this situation is solved, as this manuscript should not have been accepted for Discussions due to lack of compliance with the policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2024-3744-CEC1 -
AC1: 'Reply on CEC1 - Code Availability', Augustin Colette, 22 Jan 2025
The Copernicus Atmosphere Monitoring Service Regional Production is constituted of a distributed production system involving eleven limited area chemistry transport models. Following the issue on code availability raised by the Executive Editor of Geoscientific Model Development, the version of these eleven models as used in CAMS were made available though individual zenodo repositories. During the revision process, the section on code availability will be replaced by the following text.
Code Availability
Following the Copernicus Programme Data Policy, the Regional Production data and information are available on a full, open, and free-of-charge basis, subject to limitations concerning registration, dissemination formats, and access restrictions. The Copernicus Atmosphere Data Store is located at: https://ads.atmosphere.copernicus.eu/.
The CHIMERE model is available to registered users through the dedicated website at https://www.lmd.polytechnique.fr/chimere/, the actual version used in CAMS is available at https://zenodo.org/records/14617160.
The DEHM model used in CAMS is available at https://zenodo.org/records/14628278.
The EMEP model is available at https://github.com/metno/emep-ctm under the GPLv3 licence. The model version for CAMS is updated once or twice a year in the frame of the regular updates in the CAMS regional service. The current version is https://zenodo.org/records/14507729.
The EURAD-IM version 5.11.1 source code used in CAMS https://doi.org/10.5281/zenodo.14622487.
The GEM model is a free software that can be redistributed and/or modified under the terms of the GNU Lesser General Public License published by the Free Software Foundation. It is available on a repository administered by Environment and Climate Change Canada at https://github.com/ECCC-ASTD-MRD/gem/. GEM-AQ includes an additional source code tree accessed via an interface routine in GEM. The GEM-AQ code used in CAMS is available at https://zenodo.org/records/14720848.
The LOTOS-EUROS model is available to registered users from the website https://airqualitymodeling.tno.nl/lotos-euros/open-source-version/ the version used in CAMS is available at https://zenodo.org/records/14711996.
The MATCH model as used in CAMS is available at https://zenodo.org/records/14719885.
The FARM code embedded in the MINNI System as used in CAMS is available at https://zenodo.org/records/14650298
The MOCAGE source code used in CAMS is available at https://doi.org/10.5281/zenodo.14625973.
The MONARCH model is available at https://earth.bsc.es/gitlab/es/monarch under the GPLv3 licence. The version used in CAMS is https://zenodo.org/records/5215467.
The SILAM code is available at https://github.com/fmidev/silam-model under the GPLv3 licence. The model is updated several times a year, including two CAMS-related updates. The version used in CAMS is https://zenodo.org/records/14608973.
Citation: https://doi.org/10.5194/egusphere-2024-3744-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 23 Jan 2025
Dear authors,
Many thanks for this effort and your willingness to comply with the policy of the journal. Unfortunately, we have found that the EURAD-IM model is not available through the repository that you have linked (https://zenodo.org/records/14622487). The access to the code is restricted. Again, we can not accept this. In this way, your manuscript remains not compliant with the policy of the journal. We have to insist that you must publish the EURAD-IM code public and without limitations for access. Please, address this issue and reply to this comment as soon as possible.
Also, I would like to note that the README file for the CHIMERE model is empty. Just in case you want to fix it.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2024-3744-CEC2 -
CC1: 'Reply on CEC2', Anne Caroline Lange, 23 Jan 2025
Dear Juan A. Añel,
EURAD-IM falls in the category 2 of GMD’s core principles for code and data availability. We would like to apologize, that we forgot to add the required explanation why the EURAD-IM code is restricted.
EURAD-IM is publicly and permanently archived at https://doi.org/10.5281/zenodo.14622487. The archived code includes the entire EURAD-IM, which is historically grown including developments of multiple institutions. Furthermore, parts of EURAD-IM are adopted from license bound code, which cannot be easily made available as open source.
Therefore, the open access publication of the model is beyond our current empowerment. However, we are eager to publish new developments open access. Access to the complete EURAD-IM code can be granted on request to the editors and reviewers to enable peer review.
In accordance with the second core principle of GMD on code availability, we will add the second paragraph of this response to the code availability section of the manuscript. It is our understanding that this fulfils the GMD requirements for publications, and we look forward to your approval.
Kind regards,
Anne Caroline LangeCitation: https://doi.org/10.5194/egusphere-2024-3744-CC1 -
CEC3: 'Reply on CC1', Juan Antonio Añel, 24 Jan 2025
Dear authors,
Thanks for the answer. I think it is necessary to clarify that exceptions to our policy are for cases where sharing the code is not possible, not for those where "cannot be easily made available". That is, not easy is not equal to unfeasible. Therefore, we would need a clarification about what this means and what efforts would be necessary that make sharing the code not feasible at this point.
You state that parts of the EURAD-IM were adopted from "license bound code". This is what we expect, as for all the code that you have shared in the repositories for other models used in your manuscript. Code needs a license when you distribute it. The issue here are the terms of the license used. I guess that you could refer to the fact that the license or licenses involved are restrictive and forbid the redistribution of the code. If this is the case, we need to see the license and to understand how the EURAD-IM code or some of its parts are affected by it. With this information we will study granting an exception to the publication of EURAD-IM and your manuscript.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2024-3744-CEC3 -
AC2: 'Reply on CEC3', Augustin Colette, 04 Feb 2025
Author answer to Executive Editor:
The empty readme file for Chimere has been fixed in the new zenodo entry dated 23.01.2025 (updated link below).
Several iterations occurred with EURAD-IM developers to ensure that the code can be distributed in open source. Even if the public repository of EURAD-IM is not known yet, we hope that this answer will allow progressing with the review process.
Code Availability
Following the Copernicus Programme Data Policy, the Regional Production data and information are available on a full, open, and free-of-charge basis, subject to limitations concerning registration, dissemination formats, and access restrictions. The Copernicus Atmosphere Data Store is located at: https://ads.atmosphere.copernicus.eu/.
The CHIMERE model is available to registered users through the dedicated website at https://www.lmd.polytechnique.fr/chimere/, the actual version used in CAMS is available at https://zenodo.org/records/14724119.
The DEHM model used in CAMS is available at https://zenodo.org/records/14628278.
The EMEP model is available at https://github.com/metno/emep-ctm under the GPLv3 licence. The model version for CAMS is updated once or twice a year in the frame of the regular updates in the CAMS regional service. The current version is https://zenodo.org/records/14507729.
The EURAD-IM version 5.11.1 source code used in CAMS is available in the following restricted repository which will be made public in the course of February 2025: https://doi.org/10.5281/zenodo.14622487.
The GEM model is a free software that can be redistributed and/or modified under the terms of the GNU Lesser General Public License published by the Free Software Foundation. It is available on a repository administered by Environment and Climate Change Canada at https://github.com/ECCC-ASTD-MRD/gem/. GEM-AQ includes an additional source code tree accessed via an interface routine in GEM. The GEM-AQ code used in CAMS is available at https://zenodo.org/records/14720848.
The LOTOS-EUROS model is available to registered users from the website https://airqualitymodeling.tno.nl/lotos-euros/open-source-version/ the version used in CAMS is available at https://zenodo.org/records/14711996.
The MATCH model as used in CAMS is available at https://zenodo.org/records/14719885.
The FARM code embedded in the MINNI System as used in CAMS is available at https://zenodo.org/records/14650298
The MOCAGE source code used in CAMS is available at https://doi.org/10.5281/zenodo.14625973.
The MONARCH model is available at https://earth.bsc.es/gitlab/es/monarch under the GPLv3 licence. The version used in CAMS is https://zenodo.org/records/5215467.
The SILAM code is available at https://github.com/fmidev/silam-model under the GPLv3 licence. The model is updated several times a year, including two CAMS-related updates. The version used in CAMS is https://zenodo.org/records/14608973.
Citation: https://doi.org/10.5194/egusphere-2024-3744-AC2 -
EC1: 'Reply on AC2', Bo Zheng, 10 Mar 2025
Dear authors,
Thank you for your response. The EURAD-IM repository you provided is currently not publicly accessible. Instead, it requires interested parties to fill out a form specifying the purpose of their request to access the code files. After consultation with the Geoscientific Model Development Executive Editor, I must inform you that this procedure does not comply with the GMD Code and Data Policy. Please resolve this issue to ensure your submission meets the necessary requirements.
Bo
Citation: https://doi.org/10.5194/egusphere-2024-3744-EC1
-
EC1: 'Reply on AC2', Bo Zheng, 10 Mar 2025
-
AC2: 'Reply on CEC3', Augustin Colette, 04 Feb 2025
-
CEC3: 'Reply on CC1', Juan Antonio Añel, 24 Jan 2025
-
CC1: 'Reply on CEC2', Anne Caroline Lange, 23 Jan 2025
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 23 Jan 2025
-
AC1: 'Reply on CEC1 - Code Availability', Augustin Colette, 22 Jan 2025
-
RC1: 'Comment on egusphere-2024-3744', Anonymous Referee #1, 03 Mar 2025
This manuscript describes the design of the Copernicus Atmosphere Monitoring Service with respect to the European regional analysis, reanalysis and forecasts, based on an ensemble of 11 regional air quality models.
As the authors write, the manuscript is merely a ‘description’ than an ‘evaluation’ paper. For that reason the emphasis for this review is on a clear description of all the features, and less on questioning the actual choices made throughout, both in individual models contributing to the system, and in the overall design of the Ensemble product; Those may only be addressed through follow-up activities addressing topical discussions on individual aspects. Some questions an comments concern some aspects of overall design of the service, although also here it is merely a matter of clarifying, and discussing the choices that have been made, rather than expecting changes in the model setup.
One of the questions I had when reading the manuscript concerned the overarching ideas on how to decide on the best use and exploitation of knowledge that is encompassed by the large consortium that is contributing to this service. Providing an ensemble median product based on results from any of the individual contributing members appears very robust as a baseline solution, but I could imagine that, especially for products of more experimental nature, other choices could be made, by making use of distributed expertise and knowledge across teams.
Table 1 and general description: It would be useful to add a row in the table to compare the assimilation aspects to specify if this includes only the optimization of IC or also optimization of other processes, such as emissions and deposition, as it appears that some of the models also optimize the surface fluxes. Also, this emission optimization procedure appears to be inconsistent with one of the ‘strict requirements’ set to the ENSEMBLE members, i.e. to use specified emissions. Can the authors comment on this potential discrepancy?
Throughout the individual, contributing model descriptions, please try to adhere better to the same formulation, esp. when referring to the boundary conditions for chemical and aerosol compounds. Either refer to it as the IFS-COMPO forecasts or the CAMS-Global forecasts.
line 157 ff: What defines this selection of trace gases / aerosol types that is requested from individual models? For instance, I wonder if there is an interest in nitric acid, and sulfate as fraction of PM. On the other hand, I am a bit surprised to see a use case for glyoxal as an official product. There are different quality assurance limits
line 1228: “the evaluation is performed on about one third of the stations, deliberately left out of the assimilation workflow” : is this selection of stations fixed over time, or does it vary?
Also, how does the distribution of uncertainty in the CAMS regional system look like, e.g. in terms of spatial, temporal variability, and for different compounds.. if not going into specific details, could you indicate to what extent you assess this.
line 1261: “For this example, for the year 2021, the ENSEMBLE median has the best success ratio, but some individual models still outperform in terms of probability of detection.”. Given the importance of a good performance of the CAMS analysis for regulatory purposes, and considering that the ENSEMBLE is not the best product with respect to this metric, do the authors have recommendations on either selecting an alternative, individual ensemble member if one wants to get the best product? related, do you have an understanding what is the cause for this, with the aim to improve the ENSEMBLE product?
To what extent is performance improvement seen for the final reanalysis product compared to NRT analysis and interim analysis?
For further (mostly technical) comments I refer to the annotated manuscript attached here.
-
RC2: 'Comment on egusphere-2024-3744', Anonymous Referee #2, 14 Mar 2025
This is a nice overview of the design, implementation, and products of the CAMS regional air quality service. While the manuscript intentionally presents little analysis providing insights into what physical or chemical processes drive forecast skill and ensemble variability and could therefore be targeted for specific model improvements, the comprehensive documentation of the different modeling systems contributing to the service and the standardized way in which this documentation is provided nevertheless are an important contribution to the community. I don’t have any major comments regarding the manuscript, it is organized very clearly and the information it aims to convey is presented in a straightforward manner. The authors may want to consider the minor comments listed below when revising the manuscript.
Line 41: add “and” before “SILAM”
Line 49: remove “of” before “in the description”
Line 99: add “and” before “SILAM”
Line 109: introduce the “ADS” acronym referenced later
Line 148: change “disseminating” to “disseminated”
Figure 1: Are the individual analysis and reanalyses performed by the different modeling groups or by Meteo France (NRT/AN) and INERIS (IRA and VRA)? I think it’s the different modeling groups. In that case, maybe the white text boxes “Near Real Time NRT” and “Reanalyses” within the “Production” box could be expanded to “Centralisation of Near Real Time NRT” and “Centralisation of Reanalyses” for further clarification.
Line 155: does the 48 forecast horizon start at midnight UTC or at 08:00 UTC when the forecast is released?
Line 159: add “and” before “total Peroxy-Acetyl Nitrates (PANS)”
Line 166: if the NRT/AN product is created every day, why is it currently only available for 2021 on the ADS? Make sure to define ADS earlier as noted above.
Lines 164 – 170: It might be good to mention that the methods to create the NRT/AN product will be described in Section 3.
Lines 171 – 177: Are the IRA and VRA products generated by the individual modeling groups using the same methods used to generate their NRT/AN product (just with updated observational data), or is this performed at INERIS with potentially different methods than those used to generate the NRT/AN product?
Lines 191 – 192: Please provide details on how this split between distributed vs. withheld data is performed. Is it based on a random selection of stations? Does the selection change every day / month / year or is it fixed in time? Is the split the same between the observational datasets distributed for NRT/AN vs. IRA and VRA?
Line 219: add a comma before “and the atmosphere data store (ADS) of Copernicus”. Also see my note above on defining ADS earlier in the manuscript.
Line 240: Please provide details (or a reference providing details) on the methods used to adjust the reported emissions that are several years old to current conditions.
Line 242: No comma is needed before “(NMVOCs)”. In addition, NMVOC is already defined on line 159 does not need to be redefined here.
Line 246: Should “ventilation” be “speciation”? Which chemical and aerosol mechanism(s) is the default speciation for NMVOC and PM species provided for? Is there any guidance or harmonization on the vertical allocation of emissions from power plants and industrial sources?
Line 288: Section 2.5 stated that the IFS meteorology is available on a roughly 9 km grid, and Section 2.4 stated that all CTM operate on a domain with about 0.1 degree resolution. Why is a 0.2x0.2 degree grid mentioned here for the forcing meteorology?
Lin 294: add “and” before “snow depth”
Line 364: Same question as for the CHIMERE input meteorology - why is a 0.2x0.2 degree grid mentioned here for the forcing meteorology when the IFS forecast is available at 9 km resolution?
Line 462: In which cases are IFS chemical boundary conditions not available? How often does this happen? Similar information for how this situation is handled in EMEP should be added for all other models, too.
Line 495: Is this indeed 1300 species, or should it be 130? It seems the Bergström reference shows 158 reactions.
Lines 531 – 534: This seems to contradict the statement in Section 2.5 that all models use IFS for their forcing meteorology. In this case, IFS is only used for initial and boundary conditions. Please provide more details on the differences in physics options, land/surface model, land use characterization, etc. between IFS and WRF. Such differences mean that using WRF instead of IFS is not just an improved temporal and spatial interpolation to the EURAD geometry, but actually a distinctly different way to represent meteorology compared to most of the other models used in the ensemble.
Lines 608 – 613: Similar to the comment above regarding EURAD-IM, this also seems to contradict the statement in Section 2.5 that all models use IFS for their forcing meteorology. In contrast to EURAD-IM, it seems that the relaxation of the GEM internal fields towards the IFS target fields with a 3 hour time scale will maintain greater consistency between GEM and IFS than with the use of just initial and boundary conditions in EURAD-IM, but it would still be good to document differences in GEM physics options and IFS physics options that may influence comparisons to other models.
Lines 627 – 628: Please provide a reference for these profiles.
Lines 629 – 630: Please discuss why it is desirable to avoid the effects of short-term variability in biogenic VOC on simulated air quality. Couldn’t such effects be important in some situations?
Line 694: Why 15 km instead of the available 9 km noted in Section 2.5
Line 695: “augmented by” instead of “substantiated by”?
Line 702: Please see my earlier comment on line 462 for the EMEP model.
Lines 742 – 743: Has this been implemented now?
Lines 756 – 759: If “pairs” of IFS layers are combined to generate the MATCH layers, why are the lowest 76 IFS layers lumped into only 26 rather than 38 MATCH layers?
Line 762: which model processes use information from CLC/SEI (e.g. deposition?), and how is this information related to the “model geometry” section?
Line 765: Why is coarser resolution meteorology used for analysis compared to forecasting? If the native IFS resolution is about 9 km, wouldn’t interpolating these fields to a coarser 0.2 x 0.2 degree resolution introduce dynamic inconsistencies in the resulting fields?
Line 737: Please see my comments above about discussing how often (and why) this situation happens and then also provide information on how this situation is handed for all other models.
Lines 786 – 788: This seems to be a discussion of chemistry rather than emissions and should therefore be moved to Section 3.7.8
Lines 859 – 862: Are “diffuse emissions” gridded area emissions? Maybe “combined with” would be clearer than “summed up to” to describe the fact that point source emissions were combined with these gridded emissions prior to horizontal interpolation, and then those combined emissions were vertically allocated using GNFR-sector specific vertical allocation profiles provided by TNO in the absence of more detailed plume rise information for point sources.
Line 917: please specify the chemical species represented in the AERO3 module.
Line 947: Does MOCAGE not require any other meteorological parameters like PBL height, precipitation, soil moisture and temperature, roughness length, albedo, etc?
Lines 980 – 983: How does the deposition module obtain the necessary meteorological, surface, and soil fields given the short list of forcing meteorology listed in Section 3.9.3?
Line 1037: Why is the IFS data not used at its native resolution of 9 km (Section 2.5)?
Line 1204: change “model results deliver” to “models deliver”
Line 1209: do any models miss any of the required species? If so, how is this handled in the generation of the ensemble?
Line 1210: change “offer” to “offers”
Line 1215: Change “Figure 1” to “Figure 2”. Also discuss the reasons why the percentage of forecasts delivered on time is higher than the percentage of analyses delivered on time, given that the timeline for the forecasts is actually stricter than the timeline for the analyses.
Line 1227: Insert “and” before “PM2.5”
Line 1229: Please see my earlier comment on Section 2.3 to please more details on how the split between shared vs. withheld observational data is handled and whether it varies across time and/or NRT/AN vs. reanalysis.
Line 1236: suggest changing “a couple” to “several”
Line 1238: Will such analysis be performed and shared with the community in future publications?
Line 1247: Please provide a reference for this Key Performance Indicator and also define its acronym.
Figure 4: please define “frequency bias”
Line 1300: change “use” to “uses”
Line 1309: change “European” to “Europe”
Citation: https://doi.org/10.5194/egusphere-2024-3744-RC2
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 688 | 127 | 19 | 834 | 10 | 14 |
- HTML: 688
- PDF: 127
- XML: 19
- Total: 834
- BibTeX: 10
- EndNote: 14
Viewed (geographical distribution)
| Country | # | Views | % |
|---|---|---|---|
| United States of America | 1 | 238 | 30 |
| France | 2 | 98 | 12 |
| Germany | 3 | 71 | 8 |
| Netherlands | 4 | 51 | 6 |
| Italy | 5 | 44 | 5 |
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
- 238