the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 10 Feb 2026
EMMA-Tracker v1.0: A lifecycle-based algorithm for identifying and tracking mesoscale convective systems in observations and climate models
Abstract. Understanding the long-term climatology and physical drivers of Mesoscale Convective Systems (MCSs) in Europe is hindered by the lack of multi-decadal datasets and the difficulties distinguishing precipitation resulting from MCSs from synoptic scale frontal precipitation. Reference datasets for model evaluation that mix these physically distinct phenomena can cause misinterpreting climate model skill in representation of mesoscale convective processes. To address this, we introduce the EMMA-Tracker (Evolution-based MCS Model Assessment), a novel algorithm designed to identify and track MCSs using only standard model output variables. This intentional design choice enables a physically consistent comparison between observations and climate model ensembles, providing a pathway to investigate how MCS characteristics may evolve in a warming climate through the analysis of future projections. We apply this tracker to IMERG precipitation and ERA5-derived atmospheric instability to generate a 27-year (1998–2024) warm-season climatology— the longest reference dataset of European MCSs to date. The algorithm’s core innovation is a series of physics-based post-processing filters that utilize the system’s full spatiotemporal lifecycle to isolate coherently propagating MCSs from stationary thunderstorms and frontal rainbands. Our results show that these coherent MCSs are the dominant driver of extreme hourly precipitation. Their contribution systematically increases with hourly precipitation intensity, exceeding 60 % of heavy precipitation (P99.9) across most of continental Europe and 80 % over parts of the Mediterranean. The EMMA-Tracker provides both an observational reference for climatological studies and for targeted, process-oriented evaluation of regional and convection-permitting climate models.
Status: final response (author comments only)
- RC1: 'Comment on egusphere-2026-357', Anonymous Referee #1, 19 Mar 2026
-
CEC1: 'Comment on egusphere-2026-357 - No compliance with the policy of the journal', Juan Antonio Añel, 25 Mar 2026
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
You 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. In addition, for the input data used in your work you have linked generic sites for the GPM IMERG V07 and ERA5 data ; however, those sites do not contain specifically the data used for your work, but they are main portals where it is hard to identify and obtain the specific data used for your work. Moreover, they do not fulfil GMD’s requirements for a persistent data archive because they do not appear to have a published policy for data preservation over many years or decades (some flexibility exists over the precise length of preservation, but the policy must exist).
If we have missed a published policy which does in fact address this matter satisfactorily, please post a response linking to it. If you have any questions about this issue, please post them in a reply.
The GMD review and publication process depends on reviewers and community commentators being able to access, during the discussion phase, the code and data on which a manuscript depends, and on ensuring the provenance of replicability of the published papers for years after their publication. Please, therefore, publish your code and data in one of the appropriate repositories and reply to this comment with the relevant information (link and a permanent identifier for it (e.g. DOI)) as soon as possible. We cannot have manuscripts under discussion that do not comply with our policy.
The 'Code and Data Availability’ section must also be modified to cite the new repository locations, and corresponding references added to the bibliography.
I must note that if you do not fix this problem, we cannot continue with the peer-review process or accept your manuscript for publication in GMD.
Juan A. Añel
Geosci. Model Dev. Executive EditorCitation: https://doi.org/10.5194/egusphere-2026-357-CEC1 -
AC1: 'Reply on CEC1', David Kneidinger, 26 Mar 2026
Dear Dr. Añel,
Thank you for reviewing our manuscript and ensuring it meets GMD's rigorous Code and Data Policy.
We fully support the need for long-term replicability and have taken immediate action to resolve the archival issues you identified.
We have replaced all generic data portal links with specific, persistent DOIs that have published preservation policies, and we have permanently archived all custom code used in this study.Below is the detailed information regarding our updated compliance:
1. Code Archival We have published the exact versions of both the tracking software and the analysis scripts used for this manuscript to Zenodo to ensure permanent preservation:
- EMMA-Tracker software: https://doi.org/10.5281/zenodo.19233057
- EMMA-Analysis scripts: https://doi.org/10.5281/zenodo.19234249
2. GPM IMERG V07 Data
We have updated our citation to point to the specific persistent DOI for the exact dataset used (GPM IMERG Final Precipitation L3 Half Hourly V07) https://doi.org/10.5067/GPM/IMERG/3B-HH/07
Preservation Policy we found: This dataset is permanently archived at the NASA Goddard Earth Sciences Data and Information Services Center (GES DISC). GES DISC formally adheres to the published NASA Earth Science Data Preservation Content Specification (423-SPEC-001), which mandates the preservation of mission data and metadata in perpetuity. This policy document is formally archived at: https://doi.org/10.5067/DOC/ESO/423-SPEC-001.
3. ERA5 Data We have replaced the generic Copernicus links with the specific DOIs minted by the Climate Data Store (CDS) for the exact subsets utilized in our study.
- ERA5 hourly data on single levels: https://doi.org/10.24381/cds.adbb2d47
- ERA5 hourly data on pressure levels: https://doi.org/10.24381/cds.bd0915c6
Preservation Policy: These datasets are permanently archived by the European Centre for Medium-Range Weather Forecasts (ECMWF). Long-term preservation of these climate records is a foundational and legally binding mandate of the EU Copernicus programme, ensuring total traceability and replicability for the scientific community.
We will update the Code and Data Availability section of the manuscript accordingly and include all repository links and DOIs in the revised manuscript.
Thank you again for your guidance.
Sincerely on behalf of all authors,
David KneidingerCitation: https://doi.org/10.5194/egusphere-2026-357-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 26 Mar 2026
Dear authors,
Many thanks for your quick reply. Unfortunately, the NASA and Climate Data Store sites do not comply with our policy. These sites do not have a published policy for data preservation over many years or decades (some flexibility exists over the precise length of preservation, but the policy must exist). Actually, NASA is openly ambiguous regarding this, and their policies clearly state that future preservation of data is desirable, but it's not guaranteed. Moreover, we have very recent examples where NASA has deleted existing databases and webpages, some of them even with the CoreTrustSeal. The Climate Data Store does not have among their purposes long term preservation, but simply serve datasets for the period that they are considered relevant for application. For example, old reanalyses are deleted after a new version of them is published.
Therefore, please, reply to this comment solving these issues, by depositing the specific data used for your work in a repository that we can accept, and provide a modified Code and Data policy that complies with the policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-357-CEC2 -
AC2: 'Reply on CEC2', David Kneidinger, 26 Mar 2026
Dear Dr. Añel,
Thank you for the clarification regarding the preservation policies of NASA and the Climate Data Store. We want to fully comply with GMD’s policy, but we need your advice on how to practically achieve this given the scale of our research.
Because this is a 27-year climatological study, our raw input data consists of hourly ERA5 pressure level data and IMERG data spanning from 1998 to 2024. Even in a highly compressed format, this amounts to approximately 100 GB. Archiving this volume of data on a repository like Zenodo (which enforces a 50 GB limit per dataset) presents significant technical challenges. Furthermore, we are not sure it is useful if every researcher working with these standard, massive global reanalysis products is required to upload similar, static copies.
Given these constraints, what exactly would you suggest we do to fulfill the policy requirements?
We look forward to your specific guidance on how to best proceed so we can finalize our compliance.
Sincerely,
David Kneidinger
Citation: https://doi.org/10.5194/egusphere-2026-357-AC2 -
CEC3: 'Reply on AC2', Juan Antonio Añel, 27 Mar 2026
Dear authors,
For the case you mention, first, I would recommend you to store only the variables that you have used, in the case that you have downloaded files with additional ones that do not apply to your study.
Regarding Zenodo, it admits exceptions for repositories up to 200 GB (you have to submit a request). 100 GB is not such a big size for datasets nowadays, and something perfectly acceptable. You could split the dataset in two datasets of 50 GB, although Zenodo does not encourage it.
Also, the request to store the data is not based on judging a priori if it could be useful or not in the future for anyone, but on ensuring the provenance of the data and replicability of the work presented. Therefore, It is not an argument that should be taken into account.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-357-CEC3 -
AC3: 'Reply on CEC3', David Kneidinger, 31 Mar 2026
Dear Dr. Añel,
Thank you for your patience while we resolved the archival constraints.
To fully comply with GMD’s Code and Data Policy, we have now formally archived all raw ERA5 and IMERG input data used in this study on Zenodo.The exact input data subsets are now permanently available at the following DOIs:
- ERA5 Pressure Level Data, 1998–2010: https://doi.org/10.5281/zenodo.19347622
- ERA5 Pressure Level Data, 2011–2024: https://doi.org/10.5281/zenodo.19347730
- ERA5 Surface & IMERG Precipitation Data, 1998–2024: https://doi.org/10.5281/zenodo.19347740
We have completely rewritten the "Code and Data Availability" section of our manuscript to reflect these permanent archives while still citing the original Copernicus and NASA DOIs for proper agency attribution. The revised text is provided below for your review.
Thank you again for your strict guidance. We hope this fully satisfies the policy requirements so that we may proceed with the peer-review process.
Revised Manuscript Text:
Code and Data Availability
The EMMA-Tracker v1.0 software used in this study to identify and track systems is permanently archived on Zenodo at https://doi.org/10.5281/zenodo.19233057, with the active development repository available on GitHub (https://github.com/DavidKneidinger/emma-tracker/). The specific analysis scripts utilized for this manuscript are permanently archived at https://doi.org/10.5281/zenodo.19234249. The resulting 27-year European MCS climatology dataset (1998–2024) generated in this study is available on Zenodo (https://doi.org/10.5281/zenodo.18234275; Kneidinger, 2026).The original input datasets are provided by the NASA Goddard Earth Sciences Data and Information Services Center (GES DISC) for GPM IMERG Final Precipitation L3 Half Hourly V07 (https://doi.org/10.5067/GPM/IMERG/3B-HH/07) and the Copernicus Climate Change Service (C3S) Climate Data Store (CDS) for ERA5 hourly data on single levels (https://doi.org/10.24381/cds.adbb2d47) and pressure levels (https://doi.org/10.24381/cds.bd0915c6). To ensure strict long-term data preservation and reproducibility, the exact subsets of these raw input datasets utilized in this study have been permanently archived on Zenodo. ERA5 pressure level data for 1998–2010 (https://doi.org/10.5281/zenodo.19347622), ERA5 pressure level data for 2011–2024 (https://doi.org/10.5281/zenodo.19347730), and combined ERA5 surface and IMERG precipitation data for 1998–2024 (https://doi.org/10.5281/zenodo.19347740).
Sincerely,
David Kneidinger
Citation: https://doi.org/10.5194/egusphere-2026-357-AC3 -
CEC4: 'Reply on AC3', Juan Antonio Añel, 01 Apr 2026
Dear authors,
Many thanks. I have checked the repositories and we can consider now the current version of your manuscript in compliance with the code policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-357-CEC4
-
AC3: 'Reply on CEC3', David Kneidinger, 31 Mar 2026
-
CEC3: 'Reply on AC2', Juan Antonio Añel, 27 Mar 2026
-
AC2: 'Reply on CEC2', David Kneidinger, 26 Mar 2026
-
AC1: 'Reply on CEC1', David Kneidinger, 26 Mar 2026
-
RC2: 'Comment on egusphere-2026-357', Julia Kukulies, 07 Apr 2026
Review for "EMMA-Tracker v1.0: A lifecycle-based algorithm for identifying and tracking mesoscale convective systems in observations and climate models"
This paper introduces a novel tracking algorithm, the “EMMA Tracker,” designed to identify and track mesoscale convective systems (MCSs) over Europe. Although optimized for this region, the algorithm relies on globally available datasets and is, in principle, transferable to other regions with appropriate adjustments to its criteria and thresholds. Using this approach, the authors develop an observation-based MCS climatology derived from both satellite-retrieved precipitation and reanalysis data, while maintaining compatibility with climate model applications.
While numerous MCS tracking algorithms already exist, a key innovation of the EMMA Tracker is its integration of surface precipitation data with geopotential fields from pressure levels, enabling the inclusion of convective instability as an additional proxy for convection. Furthermore, the algorithm applies supplementary filters, such as straightness and volatility, to more effectively distinguish MCSs from frontal systems.
The paper therefore serves two main purposes. First, it introduces a novel method for tracking MCSs in regions influenced by frontal systems, where existing approaches may misclassify MCSs as fronts. Second, it presents a new dataset, along with an initial analysis of key climatological characteristics and the overall importance of MCSs over Europe. The climatological analysis shows that MCSs are a major driver of extreme precipitation events across the region, with the probability of precipitation being associated with MCSs increasing with event intensity.
Overall, the paper is well written, and the figures clearly illustrate the tracking algorithm and support the main findings. It represents an important contribution to the storm-tracking community and has potential applications for regional climate modeling. While no major additional analyses appear necessary, I list below several comments aimed at clarifying specific methodological aspects of the study.
Major comments
- Limitation of ERA5 as an instability proxy: One of my main concerns with the proposed method is that the instability proxy is derived from ERA5, which may not fully capture the atmospheric instability and convective environment, as it relies on convective parameterizations. However, I understand that the authors intend to present this tracking algorithm as a novel tool for evaluating high-resolution climate models. In the context of model evaluation, this approach is more consistent, since the simulated atmospheric instability should align with the model’s simulated convective precipitation. With this in mind, using ERA5 as the only available observational proxy for instability is still reasonable, but its limitations should be explicitly acknowledged and discussed in Section 4.3.
- Tracking on precipitation only: Likewise, I think the authors should add a brief discussion of the limitation of tracking precipitation fields only while also using spatial overlap as the method to link systems between timesteps. Feng et al. (2024) and others have used precipitation together with brightness temperature (or outgoing longwave radiation from model output) data to overcome the limitation of potential discontinuous precipitation within a MCS. Why did the authors decide to not follow this approach? Do you have any concerns that the full lifecycle of MCSs may not be captured with this approach?
- Choice of thresholds: The effectiveness analysis of each of the added criteria is great and helps a lot to better understand how the chosen criteria eliminate misclassified MCSs in what regions. However, I am wondering if the thresholds for the three criteria that are tailored to exclude frontal systems were determined through trial and error and a subjective analysis of what looks good or can the numbers be connected to a more physical reasoning? I share the other reviewer’s concern about global applicability and wonder what is the method to adjust these thresholds to make them suitable for another region?
- Choice of criteria to exclude fronts: The authors use track straightness, area volatility and environmental instability as additional criteria to distinguish MCSs from frontal systems. I am wondering why the geometric structure is not considered as this seems like a natural and easy-to-implement criterion that may be more straightforward than the track straightness or area volatility.
- Related to the comment above, why were no criteria commonly used for front tracking, such as those in Berry et al. (2011) (Berry, G., Reeder, M. J., & Jakob, C., 2011. A global climatology of atmospheric fronts. Geophysical Research Letters, 38(4)), applied? If frontal systems were explicitly identified and included in the dataset, it would allow a more rigorous assessment of the relative importance of MCSs vs. fronts in climate models’ representation of precipitation. Another alternative would have been to combine the MCS tracking with the dataset presented in Fig. 4 by Schaffer et al. (2024). Can you clarify why the chosen criteria were judged to be the more robust solution than explicitly tracking and excluding fronts?
Detailed comments
Title: First, I suggest slightly revising the title to better reflect the scope of the study. In its current form, it does not fully convey that an observation-based MCS climatology and a corresponding dataset are already presented. At the same time, the applicability to climate model data is prospective rather than demonstrated. Clarifying this distinction in the title would improve its accuracy and better align it with the actual contributions of the paper. In addition, the authors could also consider replacing “lifecycle-based” (which I believe all tracking algorithms are in some way) with what makes this tracker unique: the integration of instability data.
Python: It does not matter where, but I would certainly recommend clarifying in the manuscript that this is a python-based tracking algorithm.
Data documentation: There are some additional variables in the published netcdf files such as “active_track_touches_boundary” and “active_track_id” etc that I could not find in the documentation. Please add a description of those variables as well.
l. 55-58: This sentence seems confusing because there is some overlap between meso-alpha and synoptic scales and it also seems like the authors actually include systems larger than 200 km as well. It makes sense to distinguish between the spatial scales of organized convection and frontal systems, but it would be helpful to be more precise to which variables and processes these scales apply (primarily motion or also precipitation).
l. 63-66: I am not fully convinced by this line of reasoning. If convection is better represented but still misidentified as frontal systems, would this not simply appear as an increase in frontal systems? I suggest reformulating this argument to more clearly articulate the value of explicitly distinguishing between frontal systems and MCSs in the context of model evaluation.
l. 72: … together with satellite-retrieved surface precipitation
l. 78: “which purposefully includes convectively active frontal systems” - Do you mean here that the work of Da Silva and Haerter (2023) includes frontal systems but distinguishes them from MCSs or they just label large organized precipitation as the relevant system, no matter the underlying physical processes? That could be useful to know because if it is the latter, your dataset could be used together with their dataset.
l. 81: Write out the abbreviation here as well (it can only be found in the abstract as of now)
l. 111: Figure S3 is referenced before Figure S1 and S2 - maybe consider changing their order?
l. 123: IMERG geopotential → This seems like an error or typo
l. 164: I suggest replacing the description of this methodological step “System merging” with something like “Object identification” or more commonly used “Segmentation”. Otherwise, it sounds like this is already about the merging and splitting of systems.
l. 191: It is not entirely clear how the overlap criterion is applied in the identification of merging and splitting events. Does the overlap required to define these events also need to exceed the 10% area threshold? In addition, how are more complex situations handled? For example, if multiple non-contiguous cells at time step t are in close proximity but only some of them overlap with a single cell at time step t+1, how is this classified? Conversely, if several cells exist at time step t+1 but only one overlaps with the cell at the previous time step, how is this treated? Clarifying these cases would help improve the transparency of the tracking methodology.
l. 209: Since the dataset is published alongside this paper, I suggest clarifying that the mask files with the same dimensions of the regridded input data are also available. This is important since they usually are more useful for more advanced analyses than the track statistics only.
Fig. 2: Why is the reduced smoothing necessary to visualize the merging and splitting? Does this not mean that the smoothing may not be necessary and that there could also be an advantage in retaining the fine-scale structures of the MCSs? Also, please check the description for panel a) since there is no dashed line, but instead only a solid line and a grey area. For panel b), would it not be more appropriate to choose a timestep that shows the actual merging with the overlap rather than the non-overlapping features that are about to merge? That would at least be more consistent with the text.
Fig. 3: Would it make sense to show panel e) as a percentage of panel a), similar to Fig. 4? Panel e) indicates that the regions where most storm candidates are rejected correspond to regions with the highest MCS activity, which is not surprising. However, as the authors note, frontal systems may play a proportionally larger role in areas influenced by the North Atlantic storm tracks. This relative importance is not currently apparent. Presenting panel e) as a fraction of panel a) would provide a clearer picture of the regions where the largest relative fractions of storms are removed by the applied filters. This would also facilitate a direct comparison with Fig. 4, allowing readers to assess whether the systems filtered out, presumably to remove fronts, are indeed captured in the alternative frontal dataset.
l. 215: “rather than relying solely on instantaneous properties available during the initial detection phase” sounds like the convention of MCS trackers is to apply filters only to the MCS initiation phase. Do you have a reference for this to which tracker you compare this to? In my experience, many trackers apply filters across the lifecycle. So, I am wondering if the novelty of EMMA is maybe that the criteria are applied to EACH timestep instead of a criterion that only must be true for a given period of time, such as a certain precipitation volume during at least four hours in Feng et al. (2024)?
l. 222, 234, 242: Add a colon after each criterion
l. 243: Do you have a reference for the statement that the area of frontal systems changes more quickly than those of MCSs?
Citation: https://doi.org/10.5194/egusphere-2026-357-RC2
Viewed
Since the preprint corresponding to this journal article was posted outside of Copernicus Publications, the preprint-related metrics are limited to HTML views.
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 139 | 0 | 1 | 140 | 0 | 0 |
- HTML: 139
- PDF: 0
- XML: 1
- Total: 140
- BibTeX: 0
- EndNote: 0
Viewed (geographical distribution)
Since the preprint corresponding to this journal article was posted outside of Copernicus Publications, the preprint-related metrics are limited to HTML views.
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
This paper describes a new MCS tracking algorithm, the Evaluation-Based MCS Model Assessment (EMMA-Tracker v1.0) specifically designed to track MCSs using variables that are standard to model output, precipitation and a lifted index. The detection algorithm is relatively standard to existing tracking methods, but in the post-processing filter step, the authors use criteria on track straightness, environmental instability, and area volatility to constrain the dataset, and importantly, filter out any frontally-driven MCSs. The authors run this algorithm using IMERG v7 precipitation and a lifted index calculated from ERA5 data to generate a 27 year long warm-season MCS climatology record over Europe with the goal of creating a dataset useful for climatology studies and the process-based evaluation of models.
Through its proposal of a new MCS tracker and new MCS definition specific to a region and season and designed to benefit model evaluation, this work to some extent falls outside of the current paradigm of MCS trackers, which are typically designed to be globally generalizable, and has the potential to be an important contribution to the field. However, in the comments below I describe areas in which the argument of the authors should be strengthened, specifically highlighting where additional context and justification for their tracking algorithm choices are needed, and a few areas where their analysis does not appear to be aligned with the results in their figures.
Specific Comments:
Line 11: I understand what coherent means in the abstract after reading the full manuscript, but it was unclear to me on first read. I might suggest including specifics on what the authors use to assess MCS ‘coherence’ here.
Line 23: I think that the authors’ statement about MCS simulation being an important benchmark for climate model skill is not well-justified here. Please include additional literature (i.e., Chen et al. 2020) that better explains why this is the case.
Lines 49-60: The association of some extreme precipitation events with MCSs and fronts is not inherently contradictory. While I appreciate the framework the authors are arguing here, I would urge them to also incorporate the context of recent literature on co-occurring precipitation phenomena, such as Tsai et al. 2025. Their MCS definition also does not include the description in Schumacher and Rasmussen (2020) that describes externally-driven MCSs that are sustained by lifting associated with large-scale forcing of ascent, such as that along a frontal boundary. I agree with the overarching point argued that an evaluation dataset making a clear distinction between these two systems could be useful in evaluating certain aspects of model performance, but given that the central argument of the manuscript rests on a delineation between two phenomena that traditionally can be co-located, I would recommend the overall argument of this section be strengthened and would be aided by additional literature.
Line 73-74: It is true that infrared brightness temperature is not a standard model output, but outgoing longwave radiation, which can easily be converted, is, and as the authors note, most previous MCS trackers use brightness temperature only (i.e., Feng et al. 2025). Additionally, the co-location of precipitation in brightness temperature in MCS tracking has been shown to eliminate the cited issues with the incorporation of non-precipitating cirrus (i.e. Feng et al. 2021). I am a little bit confused about the choice to use precipitation only here. Could further justification be provided?
Line 110-111: This argument could be strengthened by referencing the high-resolution radar dataset used in the supplemental figure evaluation directly in the text.
Line 143 - 144: Interpolating temperature and specific humidity variables from 25 km to a higher resolution has the potential to introduce biases in the final data product for the lifted index, especially given that these fields are not always smoothly varying. Could the authors please explain/justify this choice further?
Line 148-149: Are the authors concerned that this smoothing would reduce the reliability of tracking on fine-scale features? Could they please explain this choice further, especially given that small-scale grid noise is not widely considered a problem in IMERG?
Line 155: I understand the rationale for using a threshold-based algorithm here to build thresholds that work for datasets of different resolutions, but I am not sure why having a threshold that adapts to a systematic bias of a model dataset is a good thing if the goal is to use this dataset for a process-oriented evaluation of models. Could this choice please be explained/justified further?
Line 225: Figure A1b could also be interpreted as, rather than the centroid shifting erratically the whole time, two distinct systems, and an erratic jump in detection between the two. What is the rationale for implementing this track straightness criteria rather than just implementing a criteria that would identify these two different components of the frontal system as two unique areas of convection?
Line 250: Similar to above, Figure A1d appears to show an MCS track that looks relatively reasonable if it were stopped a few time steps earlier, and I have seen valid MCSs masks that are more elongated in the horizontal. Could the authors please explain/justify further why the emphasis here is on eliminating this track in its entirety?
Line 259: I do not see a prominent maximum over the North Atlantic, Great Britain, and the North Sea in Figure 3a. Could the authors please clarify?
Line 278-280: A visual comparison with Morel and Sensei (2002) makes me wonder about the missing peak over the southern Mediterranean that is seen in that climatology; given that the tracking domain includes 30 degrees and northward. Could the authors please explain this discrepancy?
Figure 15: Why is masking only conducted in panel (b) and not (d)?
Line 302: I don’t necessarily see a secondary maximum of rejected frontal systems over the Balkans and Croatia in Figure 4c (where is the primary maximum?); rather, I see one cohesive maximum on the eastern portion of the Alps. Could this description please be clarified?
Line 322: I don’t think that the general pattern over eastern France in Figure 5a can be considered a maxima, given that there is a broad region showing an average of one MCS per year. Could this characterization be please explained/ clarified?
Line 401 - 402: I understand that MCSs are much less common over Europe in winter months, but if this tracking algorithm was specifically designed to filter out synoptically driven precipitation, why is it necessarily more unreliable under these conditions? Could further justification please be provided?
Line 426-428: Stronger justification is needed for why this dataset is useful for process-based evolution of models like EURO-CORDEX given that it has been stated above that it does not have the appropriate hourly resolution for direct comparison.
Technical Comments:
Line 1 and 17: Mesoscale convective system (MCS) (and future text that is defined as an acronym, such as wet hour frequency (WHF)) should always be lowercase.
Line 13: This statement is unclear. I suggest replacing ‘exceeding’ with ‘accounting for’ or another phrase to make it clear what 60% refers to here.
Line 63: It is not clear what a ‘mixed dataset’ refers to here.
Line 82: It is not clear what is meant by ‘genuine’ MCSs here. Internally driven / non-frontal associated MCSs?
Line 120: Starting here and for the remainder of this section, the authors refer to IMERG where I believe they are intending to refer to ERA5.
Line 355: The manuscript transitions from discussing MCS characteristics back to geospatial climatology here with no explanation, and left me as the reader confused.
Line 410 - 414: These sentences have multiple grammatical and punctuation errors that could be corrected for readability.
Line 419: I think this should read ‘IMERG precipitation and ERA5 data.’
Line 435: I believe the sentence should end with ‘...for evaluating organized convection.’
References:
Chen, X., O. M. Pauluis, L. R. Leung, and F. Zhang, 2020: Significant Contribution of Mesoscale Overturning to Tropical Mass and Energy Transport Revealed by the ERA5 Reanalysis. Geophysical Research Letters, 47, e2019GL085333, https://doi.org/10.1029/2019GL085333.
Feng, Z., and Coauthors, 2021: A Global High‐Resolution Mesoscale Convective System Database Using Satellite‐Derived Cloud Tops, Surface Precipitation, and Tracking. JGR Atmospheres, 126, e2020JD034202, https://doi.org/10.1029/2020JD034202.
Song, F., Z. Feng, L. R. Leung, R. A. Houze Jr., J. Wang, J. Hardin, and C. R. Homeyer, 2019: Contrasting Spring and Summer Large-Scale Environments Associated with Mesoscale Convective Systems over the U.S. Great Plains. Journal of Climate, 32, 6749–6767, https://doi.org/10.1175/JCLI-D-18-0839.1.
Tsai, M., and Coauthors, 2025: Co‐Occurring Atmospheric Features and Their Contributions to Precipitation Extremes. Journal of Geophysical Research, 130, https://doi.org/10.1029/2024JD041687.