the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 10 Apr 2025
CoCoMET v1.0: A Unified Open-Source Toolkit for Atmospheric Object Tracking and Analysis
Abstract. Advances in performance and analysis capabilities have accelerated the development of object tracking algorithms for atmospheric research. This has resulted in a growing number of studies using Lagrangian tracking techniques to analyze the evolution of atmospheric phenomena and the underlying processes. However, the increasing complexity and variety of tracking algorithms present a steep learning curve for new users and make it difficult for existing users to compare algorithm performance.
We introduce CoCoMET (Community Cloud Model Evaluation Toolkit), an open-source toolkit that addresses these issues. CoCoMET simplifies the process of running multiple tracking algorithms simultaneously and analyzing objects in both model and observational datasets by specifying parameters in a single configuration file. It standardizes input data from different sources into a consistent format and unifies the tracking output across algorithms. CoCoMET enhances the functionality of existing tracking methods by calculating additional properties such as cell growth and dissipation rates, perimeter, surface area, convexity, and irregularity. In addition, CoCoMET includes a novel method for identifying mergers and splits in 2D and 3D tracks and supports the integration of external Eulerian/stationary datasets for process studies. Its potential utility is demonstrated through examples of model intercomparison, model evaluation against observations, and comparisons between tracking algorithms. Designed for open-source environments, CoCoMET will continue to expand with future releases, incorporating more input data types and tracking algorithms.
- Preprint
(6155 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 05 Jun 2025)
-
RC1: 'Comment on egusphere-2025-1328', Anonymous Referee #1, 25 Apr 2025
reply
The manuscript introduces CoCoMET v1.0, an open-source Python toolkit that
- ingests a variety of model and observational data sets,
- launches several established tracking algorithms (tobac, MOAAP, TAMS) from a single configuration file, and
- harmonises and enriches the resulting tracks with advanced diagnostics (perimeter, volume, convexity, 2-D/3-D merging-spliting convective cells detection, etc.).
Case studies demonstrate applications to model intercomparison, model–observation evaluation and tracker intercomparison. By unifying disparate trackers under a common interface and producing a standard, analysis-ready output, CoCoMET tackles a recognised bottleneck in object-based cloud research. The toolkit is potentially a valuable community resource and, once the revisions below are addressed, I expect it to be suitable for publication in GMD. Nevertheless, before publication the manuscript would benefit from a careful language edit before resubmission. Once these points are addressed I would be happy to recommend publication.
General comments:
Please state an SPDX-recognised licence (e.g. MIT, BSD-3-Clause, GPL-3.0), the minimum supported Python version and the recommended installation method (pip or conda).
The manuscript needs a thorough language edit. Several forward-looking sentences currently placed in Sections 2 and 3 would read more naturally in Section 4 (Future development).
Although the text advertises “parallelised execution”, no timing or scaling information is given. Even approximate wall-clock times and memory footprints for different cases would greatly assist prospective users.
Section 2.4 claims a novel merger–split method but offers only schematic examples; please provide quantitative validation (e.g. skill scores or comparison with tobac’s own split/merge routine).
Output format – CoCoMET saves results in Python pickles, which are opaque outside the Python ecosystem and brittle across versions. Please justify the choice against an export option to self-describing format (e.g. NetCDF).
Terminology – The distinction between feature, cell and object is unclear. A short glossary or an early discussion (in Section 2) would help. Explicitly state that v1.0 is designed and validated for convective phenomena (and convective cells), even though the architecture could handle other objects.
New developed function for detecting 2D and 3D merging and splitting: Could you provide an intercomparison between other’s tracker merging and splitting and you method?
CoCoMET output format: The new toolkit CoCoMET highlights that it simplifies the run of trackers on different type of data, the analysis of trackers’ outputs and their intercomparisons. However, most of the trackers output in the NetCDF format which is conveniently easy to use and process, and CoComet outputs have binary pickle format which can’t be read without the CoComet specific routine. Please comment on whether this choice could limit long-term usability for users who rely on NetCDF.
Specific comments
Introduction (lines 55–64). The problem statement would be stronger if you cited concrete examples of prior tracker-intercomparison and model-evaluation studies.
Introduction (74–79). Here the terms feature/cell are introduced but not defined; please add definitions and explain that CoCoMET v1.0 focuses on convective clouds and MCSs.
Also clarify the meaning of “life cycle.” Which lifecycle are you referring to? The one of the “cell” of the “feature”.Introduction (closing paragraph). Highlight explicitly that CoCoMET can accommodate both observational and model data, and summarise its community value.
Lines 87–95 and 404–406. These sentences discuss future extensions (e.g. extension to ERA5 data) and belong in Section 4.
L 90-95. Do you perform any grid remapping before applying the tracking? How does the package handles different grid as it would have to for ICON or other models with non regular meshes?
Section2
Figure 2, together with the surrounding text leave it ambiguous whether CoCoMET executes atmospheric models. Please state explicitly whether model execution is in scope.
In Section 2.1.1 the final paragraph contains essential information but lacks context. A short lead-in sentence would help. In addition, please explain why precipitation rates are recomputed for RAMS and WRF (lines 137–140), whether these fields are required for identifying precipitation cores in MCS tracking, and, if so, consider adding a short dedicated sub-subsection on precipitation. At present this need becomes clear only later in the Meso-NH discussion (line 149).
L139-140. Move variable names RAINC and RAINNC inside parentheses and move the explanatory text outside; re-phrase for clarity.
L 144- Add references for SURFEX and the cloud-microphysics schemes used in Meso-NH. Throughout, write “Meso-NH,” not “MesoNH.”
Generally in section 2, make it clear what belong to models and what belong to CoComet.
Section 2.2 (Implemented trackers)
Briefly explain how additional trackers can be integrated via plug-ins, so the community understands how to contribute.
L146, numerical variables or meteorological variables?
L146-147. Specify whether radar reflectivity is calculated in Meso-NH or inside CoCoMET.
L161 Briefly explain the rationale for selecting 30, 40 and 50 dBZ thresholds.
L170 – Please replace ‘recent updates’ with a version-specific reference.” In 10 years from now, maybe the updates would not be recent anymore.
L189 and L206. Clarify what “types of model outputs” means: file formats, variable sets or both? The three weather models you are describing in the paper?
Section 2.3 (Output unification). State which new diagnostics are unique to CoCoMET and which already exist in individual trackers. Provide a brief explanation of 2-D vs 3-D features for non-experts.
L209- Are the deep convective cell/MCSs trackers really sharing outputs? Or are they just similar?
L221-223. Please explain the new merging/splitting method, or refer to section 2.4.
L252-253. This is nice. I want to know more example for other features.
Equation 1. V and A are introduced without their subscripts. Consider adding the subscripts in the text.
Sec2.3.6. Clarify whether 3-D features are reconstructed from stacked 2-D features.
Section 2.4 (title and content). Define “merge” and “split” early in the subsection title or first sentence
Mergers and splits are not defined (only later L315) and feel like jargon.
Explain all free parameters (20 % perimeter, 110 % search radius, 50 % overlap, look-ahead of 2 time-steps) and discuss sensitivity.
L322- pi should be written with its symbol here. “rsearch”, consider subsripting the “search”.
Equations 2 and 3. The symbol V is reused with a different meaning; please adopt a new symbol for the background threshold, and clarify square root of 2 or of 2 times r_search.
L358: This forward-looking sentence belongs in the Introduction.
Equation 3: same comments as for equation 2.
L369. Specify what the third dimension represents (vertical coordinate?).
Section2.5
L390- clarify whether CoCoMET currently ingests UAV data or whether this is planned.
Section 3
The configuration system is not fully clear to me: does CoCoMET simply provide a master file that forwards settings to each tracker’s native configuration, or does it translate all tracker parameters into a single, unified schema with consistent key names? If the former is true, please clarify the practical benefit of advertising “one configuration file” and explain how this approach adds value relative to running each tracker individually.
L437. Check date format against journal style.
L439. Use consistent SI notation (e.g. m s⁻¹).
L446- A few times you are refering in the text that a config file is available in Weiner et al (2025). That would be nice to have the config file either in your repository or to have a brief discussion of what the config file is.
L450. “increasing trend”, make it intemporal.
L455- Since Hahn et al. is still in review, consider placing the figure in supplementary material.
L460 and Fig. 8 The caption uses “life-cycle bin” whereas the axis label reads “normalised lifetime”. In which unit is the lifetime? Hours?
Section 4 (Future development). Sections 4.2 and 4.3 both discuss linking to additional external data sets; consider merging them or clarifying the distinction.
Explain what you mean by “thermodynamic data sets” and by “external” data.
L492. Check spelling for “PyFLEXTRKR” and cite TempestExtremes.
The final sentence of Section 4 repeats material already discussed. Please also check “Stage VI” throughout the manuscript.
Scaling limitations. Briefly discuss potential bottlenecks for global domains or multi-year archives (memory, I/O, parallel efficiency)
Fig.2 What do the grey arrow mean?. The top ones look like they are mentionning preprocessing or liking data, and the bottom one look like they are for running the tracker. Is the big blue arrow for mentionning the output of CoCoMET? It would be nice to see what are inputs and what are outputs.
Fig. 3. It would be nice to see a feature of convexity = 1 and a feature os convexity very close to 0.
Fig. 4. explain the colour scheme.Figures 5–6 (merge/split examples) lack variable names, thresholds
Fig. 7. Caption: “MesoHN” → “Meso-NH” and unify axis units.
Fig. 8. Observed and simulated, please specify which one is which.
Fig. 9. maybe add a tick for each hour for clarity.
References: Check DOI formatting; several have duplicated “https://doi.org/https://doi.org”.
Replace straight quotes with typographic quotes, and use consistent en-/em-dashes.
Citation: https://doi.org/10.5194/egusphere-2025-1328-RC1
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 107 | 23 | 4 | 134 | 2 | 2 |
- HTML: 107
- PDF: 23
- XML: 4
- Total: 134
- BibTeX: 2
- EndNote: 2
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1