RAMS is a highly versatile numerical model developed at Colorado State University for simulating and forecasting meteorological phenomena. It consists of three main components: an atmospheric model for executing the simulations, a data analysis package for processing initial meteorological data, and a post-processing tool for visualizing and analyzing model output .

The raw output data for each RAMS simulation case consists of two files: a netCDF file containing the numerical data for simulated variables and a text file storing metadata for the simulation (e.g., variable dimensions, model grid spacing). A more detailed description of RAMS can be found at https://rams.atmos.colostate.edu/detailed.html (last access: 1 March 2025). A separate function in CoCoMET (rams_configure.py) is implemented to parse the metadata file and extract essential information required for tracking, such as the simulation start time, variable dimensions, grid spacings, and map projection.

Radar reflectivity is computed following the methods outlined in the RAMS source code (https://github.com/RAMSmodel/RAMS/tree/main, last access: 1 March 2025) which assumes the hydrometeors (rain, pristine ice, snow, aggregates, graupel, hail) are spherical and their number concentrations are represented by gamma distributions. Brightness temperature is computed from the outgoing longwave radiation using the Stefan Boltzmann law , and the same method also applies to WRF and Meso-NH simulations.

RAMS does not provide direct output variables for surface precipitation rate, a key variable commonly used for tracking convective cores in both isolated cells and MCSs. Therefore, CoCoMET includes a function to calculate surface precipitation rate based on additional model outputs. It can be calculated using different settings, determined by the user's input for calculation_type in the CoCoMET configuration file. If calculation_type is set to “surface time averaged precipitation rate” (default), the change in the sum of all surface accumulative hydrometeor mixing ratio rates (rain, pristine ice, snow, aggregates, graupel, hail, and drizzle) over consecutive model time steps is used for tracking. If set to “surface instantaneous precipitation rate”, the sum of all surface hydrometeor rates simulated at each model time step is used for tracking. Finally, for “volumetric instantaneous precipitation rate”, the sum of all 3D hydrometeor rates derived at each model time step is used for tracking.

The WRF model is a widely-used mesoscale numerical weather prediction system developed for both atmospheric research and operational forecasting . It includes two dynamical cores, a data assimilation system, and a software framework designed for parallel computing and system expansion. The model is applicable to a broad spectrum of meteorological studies, covering spatial scales from a few meters to thousands of kilometers. The output of WRF is in netCDF format, containing both numerical variable data and metadata.

In addition to the direct outputs of WRF, which may be selected for tracking (e.g., updraft velocity and rain mixing ratio), we also implement functions to calculate radar reflectivity (when it is not directly output by WRF) using the methodology from . The calculation is based on the wrf.dbz function in the wrf-python open-source package . The hydrometeors involved in the calculation include rain, snow, and graupel. In the next version of CoCoMET, we plan to replace the current equations used for calculating radar reflectivity with a radar simulator (e.g., The Cloud-resolving model Radar SIMulator; CR-SIM; ). This upgrade will extend the reflectivity calculation's applicability to simulations using various microphysical schemes (different hydrometeor types), enhancing CoCoMET’s versatility.

As with RAMS, WRF does not provide direct output variables for surface precipitation rate. In CoCoMET, at a given time step, it is calculated using the methodology used to describe “surface time averaged precipitation rate” in RAMS, and is provided as the input “pr” to CoCoMET. It is estimated from the difference in accumulated precipitation between consecutive time steps. The accumulated precipitation is the sum of accumulated convective precipitation (RAINC) and accumulated grid-scale precipitation (RAINNC).

Meso-NH is a non-hydrostatic mesoscale atmospheric model developed by the French research community . The model supports simulations across a wide range of scales, from large eddy to synoptic, with advanced physical parameterizations for clouds and precipitation . Coupled with the SURFEX surface model , it represents surface-atmosphere interactions across different surface types. Meso-NH features grid nesting for multi-scale simulations, operates in 1D, 2D, or 3D, and it includes a chemistry module and a lightning module.

Meso-NH outputs data in netCDF format, similar to WRF, containing both meteorological variable values and associated metadata. Radar reflectivity is calculated in the same way as WRF inside CoCoMET with plans to upgrade using CR-SIM. Unlike RAMS and WRF, Meso-NH provides output variables for surface precipitation rate, which can be directly used for tracking precipitation cores. Since radar reflectivity is not a direct output from Meso-NH, users can calculate it using the same method described in the section above for WRF.

Tobac is a Python-based, open-source framework designed to identify, track, and analyze atmospheric features in both 2D and 3D datasets. The package is designed in a modular framework with three main steps. In the first step, regions satisfying progressively restrictive thresholds (e.g., 30, 40, 50 dBZ; ) in a given variable field are identified as “features” (Table ). Feature identification is followed by a “segmentation” step wherein the area (for 2D datasets) or volume (for 3D datasets) associated with each feature is estimated at each time step. Finally, features identified across successive time steps are linked based on a search within a defined radius of their projected positions. Tobac is flexible as feature segmentation can be completed after either the identification or linking step, and can be bypassed if a user does not need spatial information for the tracked features. More specific details associated with each step are provided by and .

Tobac v1.5.3 introduced an increase in computational efficiency, tracking of 3D features, handling of feature splits and mergers, internal spectral filtering, and support for periodic boundary conditions, making it more robust for analyzing atmospheric data. Tobac has been widely used for tracking convective clouds, updrafts, precipitation systems, and other meteorological phenomena in both model simulations and observational datasets (e.g., ). We ensure that unique elements of tobac, such as parallel computing and its ability to track any type of feature within a gridded field (even non-meteorological ones), are incorporated into CoCoMET. This tracker is integrated with all input data streams implemented in the current version of CoCoMET.

The MOAAP algorithm is designed to identify and track a wide range of atmospheric features within a unified framework. It processes both regional and global datasets to detect and analyze phenomena such as tropical and extratropical cyclones, mid-level cyclones, cut-off lows, anticyclones, atmospheric rivers, jet streams, fronts, MCSs, and tropical waves .

MOAAP begins by applying thresholding methods to classify grid points corresponding to specific atmospheric phenomena. It then generates label maps that delineate the spatial extent of each identified feature, with unique identification criteria tailored to each type of feature (e.g., vorticity for cyclones, moisture flux for atmospheric rivers). Once features are identified, MOAAP employs a nearest-neighbor approach and spatial overlap techniques to track the movement of features across consecutive time steps. The linking process primarily relies on a simple connectedness principle, i.e. adjacency in space and time between detected features. Once features are initially detected, that information is fed to a two-pass binary connected-component labeling algorithm for linking. MOAAP accounts for features that merge, split, or dissipate during the tracking process, maintaining accuracy in complex scenarios. After tracking, MOAAP generates comprehensive outputs that include all detected features and their trajectories.

This tracker is currently integrated with only three model outputs (i.e., WRF, RAMS, Meso-HN) in CoCoMET, as it requires a set of variables (see https://github.com/AndreasPrein/MOAAP/wiki, last access: 1 December 2024) to track atmospheric phenomena that are often unavailable in a single observational dataset.

The Tracking Algorithm for Mesoscale Convective Systems (TAMS) is a Python-based tool which operates in a series of steps: identification, tracking, classification, and variable assignment. It is primarily used to analyze organized cloud systems in both observational and model data using Infrared brightness temperature (Tb) or cloud top temperature . TAMS can handle data from both structured and unstructured grids, which makes it adaptable for various types of input datasets.

By default, TAMS identifies cloud elements by applying the following threshold criteria: an edge Tb or cloud top temperature below 235 K (a free parameter in TAMS) within an area larger than 4000 km² (a fixed parameter) and an embedded cold core with a Tb or cloud top temperature below 219 K (a free parameter) that covers an area larger than 10 km² (a fixed parameter) and is detected at least once during the lifetime of the MCS.

After identifying the cloud elements, TAMS uses backward linking to group cloud elements that show significant overlap with projected elements from the previous time steps, creating MCS tracks. TAMS classifies each tracked event into different categories based on the size, structure, and longevity of the tracked MCSs. The detailed explanation of each category can be found in . Note that this tracker is currently integrated with three types of model outputs and GOES observations in CoCoMET.

The perimeter of a tracked 2D feature (in km) is calculated by identifying and summing the lengths of its edge segments. First, the segmentation mask is used to identify the feature's boundary by checking each grid point in the feature. A point is considered an edge if at least one of its four neighboring points lies outside the feature. The length of each edge segment is calculated using the projection coordinates, then all edge segments are summed to determine the total perimeter. This process is repeated for each feature at each time step. The feature perimeter function is used extensively in the newly developed methodology within CoCoMET to identify splits and mergers between objects tracked in two-dimensional space.

The 2D feature area is determined through segmentation, resulting in a masked array that identifies grid points occupied by the feature at each time step. The area, expressed in square kilometers, is calculated as the product of the number of grid points within the feature and the area of an individual grid box. For 3D tracking, the feature area at a given height level can be calculated by specifying the height (2 km by default) within the configuration file in the segmentation function. This variable is important in multiple aspects of atmospheric sciences. For example, the extent of cloud cover directly influences Earth's energy balance (e.g., ). Additionally, the size and distribution of precipitation areas determine the volume and distribution of rainfall, affecting water resource availability (e.g., ).

In 3D tracking, the surface area of each feature is calculated by checking every grid point in the feature segmentation. For each point, the algorithm looks at its six connected neighboring points in the cubic orientation. If any of these neighbors is not part of the feature, the current grid point is considered “exposed”, and the area of the exposed side is calculated using the projection coordinates. This process is repeated for all grid points, and the surface areas are summed up. The final result is in square kilometers and is stored for each feature in each time step for a tracked cell. The feature surface area function is used extensively in the newly developed methodology within CoCoMET to identify splits and mergers between objects tracked in three-dimensional space.

The feature volume can be calculated when tracking cells using 3D data. It is determined by summing the volumes of all the grid boxes that define a feature according to the segmentation results. The final output is provided in cubic kilometers and is stored for each feature in each time step for a tracked cell. This variable has been frequently used to analyze cloud and precipitation characteristics. For instance, found that a warmer condition may increase the precipitation volume produced by MCSs by up to 80 %.

The irregularity or roughness of the edges of a 2D feature is quantified using convexity, a measure of how much a shape deviates from being convex. Convexity is defined as the ratio of the perimeter of the object's convex hull to the perimeter of the object itself. The convex hull is the smallest convex shape that fully encloses the object. A value close to 1 indicates a smooth, compact shape (Fig. b), while lower values suggest jagged or complex boundaries (Fig. a). This is useful in identifying cloud structures/morphology in meteorological data or model simulations and the potential influence by entrainment and mixing processes (e.g., ).

For a 3D feature, convexity is similarly used to evaluate the irregularity of an object's surface. Instead of using perimeter, the ratio is calculated using surface area – comparing the actual surface area of the object to the surface area of its convex hull. A value close to 1 indicates a compact, smooth structure, while a lower value suggests the object has indentations or rough, uneven surfaces. In both cases, convexity provides a quantitative measure of shape complexity of tracked clouds and/or system. Although such parameters have gained little popularity, they have the potential to facilitate studies, such as classifying different cloud fields (e.g., ) and determining whether an updraft is more thermal-like or plume-like (e.g., ).

We also provide another way of quantifying the irregularity of a feature in 3D, which is called sphericity. Sphericity is a measure that compares the surface area of a perfect sphere with the same volume to the actual surface area of the feature being analyzed.

Mathematically, sphericity (ψ) is given by the equation: 1Ψ=π13(6V)23A, where V is the volume of the feature, A is the surface area of the feature.

In Eq. (1), the numerator represents the surface area of a sphere with the same volume as the feature, and the denominator is the actual surface area of the feature. By comparing these two quantities, sphericity provides a way to quantify how close the feature is to a perfect sphere, with values approaching 1 for more spherical shapes and values much less than 1 for highly irregular shapes. The sphericity is calculated for each feature in each time step for a tracked cell.

The maximum height of a variable is defined as the 95th percentile of altitudes (in km above ground level) where the selected variable exceeds a specified threshold across the entire segmented feature area.

For 3D tracking, this calculation is straightforward on a 3D variable of interest, as height data is directly available within the segmented feature. For 2D tracking, if the variable of interest is 3D with a vertical dimension, the maximum height can still be determined. The process involves examining the vertical columns within the horizontally tracked feature area and identifying the highest altitudes where the variable exceeds the given threshold (an independent threshold from tracking and segmentation).

For example, if tracking is performed based on updraft at 6 km altitude, and a threshold of 5 m s⁻¹ is given for the calculation of the maximum height, the maximum height of the updraft corresponds to the highest altitude (95th percentile) on the same 2D area as the segmented feature where the updraft velocity surpasses 5 m s⁻¹. The strength of convective clouds or the depth of convective cloud cores is often represented using parameters such as the Echo Top Height (e.g., ) which can now be derived automatically using CoCoMET.

The cell growth and dissipation rates are determined by calculating the rate of change in a targeted cell property (e.g., area for 2D tracking, volume for 3D tracking). For each cell, this property is taken at each frame/time step where the cell exists. The difference in the cell property between consecutive frames is divided by the time interval between the frames to estimate the rate of change in cell property. The cell growth/dissipation rate for the last feature along an object's life cycle are left as NaN. Such estimates can help understand temporal changes in cloud updraft width and the role of entrainment to determine its influence on convective cloud depth (e.g., ).

The propagation speed of a tracked cell is determined by estimating its position change over consecutive time steps. For each feature, the velocity is calculated as the displacement of the cell between its current frame and its next frame divided by the time interval. The velocity is output as a unit vector including propagation speed along two (y, x) or three dimensions (z, y, x). The speed (m s⁻¹) is output as the magnitude of the original velocity vector. The velocity vector and speed for the last feature along an object's life cycle are left as NaN.

These quantities are particularly useful for examining the relative influence of local and synoptic-level forcings on cloud fields by comparing the propagation speed and direction of individual clouds against the background wind speed and direction .

The identification of mergers and splits follows the methodology of , with modifications to improve adaptability to users' needs (Fig. ).

First, we Identify candidate pairs. Features that share a common border (referred to as “touching” features) exceeding a user-defined percentage of their perimeter are flagged as potential merging/splitting features. The default value is set to 20 %. Next, we define the search region for feature area calculation. Each feature is approximated as a circle with a radius rfeature, which is calculated by adding up all “edge” grid cells (those which are not completely surrounded by segmented grid points) to define a circumference and divide this by 2×π to get the radius in “grid points”. The radius is then expanded to rsearch using a user-defined weighting to define a search region for edge pixels for each feature. By default, the search region is set to 110 % of the radius of each feature, making rsearch=1.1×rfeature. A square is created with the same center as the circle and with side length 2×rsearch. Within this square, each grid point is assigned a score based on its proximity to the feature core (point of maximum value) and its intensity relative to a background threshold. The calculation of the score (S) follows the formula below: 2Si,j=ω1Ri,j-ARmax⁡-A-ω2‖(i,j)-(i0,j0)‖22rsearch, where R represents the variable field, Rmax⁡ is the variable value at the feature core, i0, j0 is the location of the feature core, A is a new background threshold for the tracked variable, set by the user (20 by default for radar reflectivity input), and ω1 and ω2 present adjustable weights that allow users to fine-tune the relative influence of intensity versus distance in determining mergers or splits. The default values for ω1 and ω2 are both 1.

If the score for a given feature exceeds the threshold, which is by default 0, it is included as part of a new mask. After applying this process to both features in the pair, the resulting masks are overlaid, and the overlap area is calculated as a percentage of either feature's area mask. Pairs that exceed a certain percentage area overlap threshold (50 % by default) move to the final step and are referred to as potential merging or splitting pairs.

For these potential merging or splitting pairs, we look forward in time over a user-specified number of time steps (2 by default). If one cell persists and the other does not, this is classified as a merge event. However, if both features exist (or both do not exist) in the subsequent time steps, no merging event is confirmed. In cases where neither feature exists anymore, meaning both features are no longer tracked, they may have moved closer to each other but dissipated without merging, or they could have merged into other cells along the way.

At the same time, for these potential merging or splitting pairs, we look backward in time over a user-specified number of time steps (2 by default). If one feature exists consistently across the time steps while the other does not, this is confirmed as a splitting event. However, if both features exist (or both do not exist) in these time steps, no splitting event is recorded.

Unlike the original approach in , which focuses on radar reflectivity only, this version in CoCoMET allows tracking based on any user-selected variable. For variables with inverse behavior (e.g., Tb, where lower values reflect stronger convection), the calculation is adjusted by inverting the variable field before the calculations. Examples of merging and splitting events are shown separately in Figs.  and , respectively. Details about all parameters are explained in the Appendix B.

The output of this function is stored in two Pandas DataFrames (two tables), which record the time of the event (merge or split) and the cell IDs involved. In the merger DataFrame, each row contains a list of the two frames during which the merger occurred, a tuple of the two cell IDs of the parent cells involved, and the cell ID of the merged cell. In the split DataFrame, each row contains a list of the two frames during which the split occurred, the cell ID of the split cell, and a tuple containing the cell IDs of the two child cells.

Overall, this approach provides a flexible and robust way to track structural changes in 2D convective cells while allowing users to customize parameters for different atmospheric variables.

We apply a similar approach to identifying mergers and splits in 3D as described for 2D data, with adjustments to account for the third dimension.

To speed up the process, before identifying mergers and splits, the dataset is filtered to focus on cells in the time steps immediately before feature disappearance or immediately after feature appearance. These are the only two instances when a merge or split can occur, so only the cells identified at these time steps are analyzed. This filtering step also pre-classifies all cells as being involved in either a merge or a split, which will be used in the final step of the identification process.

Instead of perimeter, we use the surface area of 3D objects to identify touching features at a given time step. In other words, for each feature, we evaluate how much of its surface area is shared with an adjacent feature to determine the potential for a merge/split. Rather than modeling the feature area as a circle in 2D, we use a sphere with an adjustable radius, extended in three dimensions. Similarly to the 2D process, we generate a cube with the same center as the sphere and side length 2×rsearch. Within the search cube, each grid point is assigned a score calculated using a formula similar to Eq. (2) below: 3Si,j,k=ω1Ri,j,k-ARmax⁡-A-ω2‖(i,j,k)-(i0,j0,k0)‖23rsearch, where k is the vertical dimension. If the score of a grid point exceeds a user-defined threshold, it is considered part of the new mask. The overlap volume between two masks is then calculated to assess whether a merge or split has occurred. If the overlap volume exceeds a user-defined percentage of either mask's original volume, the event is confirmed as either a merge or split, based on the classification from the initial step.

Note that Tobac has a separate function for identifying mergers and splits, while MOAAP and TAMS do not output information about them. Tobac applies user-defined thresholds for maximum allowed spatial and temporal separations between cells to be considered potential mergers/splits. This is then used in an implementation of Kruskal's algorithm to construct a minimum Euclidean distance spanning tree. This tree structure, formed over spatial and temporal domains, is what defines merge or split events. Unfortunately, there are no directly comparable thresholds or parameters between the tobac and CoCoMET algorithms that would allow a fair comparison. Therefore, we performed our comparison using the default merge/split settings provided by CoCoMET and several settings for tobac in Figs.  and in Appendix C. It is important to note that these thresholds should be tailored to the specific application, as appropriate settings may differ between isolated and organized convection.

A key enhancement in the CoCoMET package is the integration of Lagrangian and Eulerian datasets for studying clouds and other atmospheric systems. While cell tracking provides a Lagrangian perspective on the lifecycle of a tracked property, not all atmospheric measurements are collected in a manner that is suitable for tracking. Many observations, such as those from the Atmospheric Radiation Measurement (ARM) user facility , are collected at fixed locations with one dimension (time) or two dimensions (time, height). Examples include but not limited to vertical pointing cloud radars and lidars, aerosol measurements at the surface or along a tethered balloon system, and precipitation measurements (disdrometers). To fully leverage these diverse datasets, it is essential to link cloud lifecycle stages with time-height observations, enabling a more comprehensive analysis of cloud structure and evolution (e.g., ).

To achieve this, we developed a function (extract_arm_product) that extracts Eulerian measurements at each time step of the tracked cells. This function aligns the tracking frames with their corresponding timestamps and matches them to the nearest available Eulerian data time. It also calculates the time difference (time_delta) between the tracked cell's timestamp and the Eulerian data time, where positive values indicate Eulerian data recorded after the tracked frame and negative values indicate earlier measurements. Additionally, the function identifies the closest feature and cell to a specified ground-based measurement site or location, providing their respective IDs along with the distance between the Eulerian measurement site and the nearest tracked feature in kilometers. Such capabilities can easily be extrapolated to include distance from observations collected using mobile platforms like research aircrafts or Uncrewed Aerial Vehicles (UAVs), which will be considered in future development.

To study aerosol-cloud-environment interactions and related processes, it is essential to link cloud properties with their surrounding environmental conditions. One key dataset we incorporate is the ARM INTERPSONDE data , from which we derive convective indices such as Convective Available Potential Energy (CAPE), Convective Inhibition (CIN), and low-level wind shear (0–5 km), following the methodology of .

These indices can be calculated using parcel theory under different assumptions, considering both irreversible pseudo-adiabatic and reversible moist adiabatic ascents. In the pseudo-adiabatic process, we assume an undiluted parcel ascent while neglecting hydrometeor loading. Users can also choose to include ice-phase processes, which introduce additional buoyancy above the melting level due to latent heat release during freezing. The function also allows users to specify initial parcels, with choices among the most unstable parcel, surface parcel, and mixed layer parcel. The surface-based parcel is defined as the parcel at the lowest sounding data level; the most unstable parcel is defined as the parcel that has the greatest virtual temperature in the lowest levels above surface (700 mb as default and can be changed by users); the mixing-layer parcel is defined as the parcel with properties of the mean of the user-defined boundary layer (500 m as default).

In summary, the following properties are unique to CoCoMET: 2D Feature Perimeter, Feature Surface Area, Feature Irregularity, Maximum height of a Variable of Interest, Cell growth and dissipation rates, Feature Convexity and Sphericity, Linking to ARM Datasets, Calculation and linking to sounding data.

CoCoMET facilitates model intercomparison studies by enabling the comparison of different numerical model outputs for the same event. An example of this is illustrated in Fig. , where we compare tracked 3D updrafts from outputs of WRF and RAMS for a case that occurred on 19 June 2013 over the Houston region. The thresholds for defining an updraft are set at 3, 5, and 10 m s⁻¹, and we use tobac for the tracking process. The temporal resolution of the model outputs is 5 min, with simulations running for a duration of 4 h from 16:00–20:00 local time. The details of this case and the corresponding model setups are presented in .

We present histograms of eight selected updraft characteristics in Fig. . The maximum volume, maximum updraft velocity, and maximum updraft height represent the maximum values of these variables captured during the cell's lifetime. The remaining variables are feature-based, meaning that the values for each individual feature within the cell are plotted. In general, both models exhibit similar statistics for most variables although small differences appear for some variables. While the scientific reasons behind these differences are beyond the scope of this study, our primary goal is to demonstrate the utility of CoCoMET in facilitating this type of comparison. The CONFIG is available in . After running this CONFIG, users will obtain outputs from tobac for three inputs simultaneously without additional steps.

For model evaluation, conventional methods typically compare bulk properties of clouds or other atmospheric variables; however, there is an increasing trend over the past decade toward comparing properties at the individual cloud level, particularly through the analysis of cell life cycles. This approach not only provides a more detailed assessment of clouds but also proves invaluable when evaluating regional and Earth system models, especially in relation to the diurnal cycle of cloud initiation and evolution on a global scale.

We have utilized CoCoMET to evaluate multi-case ensemble simulations of sea breeze convection days over the Houston region, as demonstrated in . This example highlights the effectiveness of CoCoMET in facilitating such comparisons.

In Fig. , we provide another example of evaluating RAMS simulations used in Fig.  with NEXRAD observations for the same case. Tobac is employed for tracking, with tracking performed on radar reflectivity at 2 km height. The thresholds for defining tracked features are set at 30, 40, 50 dBZ. The horizontal grid spacings of the NEXRAD data and the RAMS simulations are both 1 km. The temporal resolution of both datasets are similar, around 5 min. In Fig. , both RAMS and NEXRAD show peak cell area and reflectivity during the mature stage of convection (around lifecycle bin 4), as expected (e.g., ). The cell area growth rate transitions from positive in the earlier stage to negative in the later stage, which is consistent between observations and simulations for this particular case. These results give us confidence in the tracking method and the implementation in CoCoMET.

This example is achieved by specifying parameters in a single CONFIG (available in ), which highlights its streamlined workflow and allows for rapid analysis. This makes it a powerful tool for both single-case and multi-case evaluations with observational data, identifying key differences and similarities between the two, ultimately accelerating model evaluation and development. This time-efficient processing also ensures that comparisons can be made over extended periods, which is particularly valuable for long-term studies, such as those involving seasonal or annual model performance.

Differences in tracked cell properties are expected when using different trackers due to the varying designs and underlying algorithms of these methods. Whether such differences significantly affect the conclusions drawn in studies related to the tracked systems is worth exploring further. One approach to quantify these differences is to track the same system using multiple trackers and analyze how variations in tracking results influence subsequent findings. This process can help improve the robustness of scientific conclusions.

CoCoMET is specifically designed to simplify this task by allowing users to configure and execute multiple trackers simultaneously through specifications in the configuration file. The toolkit returns results from all selected trackers in a standardized format, making it easier to compare and interpret differences.

We illustrate this process with an example in Fig. , where we track brightness temperature from CONUS404 WRF simulations using two thresholds, 219 and 235 K, with three trackers: TAMS, MOAAP, and tobac. This case occurred on 19 June 2013, and the trackers were applied over a 24 h period. The CONUS404 simulations are performed using WRF version 3.9.1.1, with horizontal grid-spacing of 4 km and temporal resolution of one hour. Figure  shows the initiation location and timing (colors) of tracked cells for all trackers.

Overall, all trackers identify cells in the same general region, but tobac detects more cells compared to TAMS and MOAAP. This difference arises because TAMS and MOAAP are specifically designed to track large, organized systems, whereas tobac is more focused on identifying isolated convective cells. Compared to TAMS, MOAAP applies additional thresholds internally which limits the number of cases tracked. Despite the difference in the number of tracked cells, the initiation timings are well captured by all trackers, demonstrating consistency in some aspects across the methods. We performed a sensitivity test by limiting tracked cells to a minimum area of 4000 km² and a minimum lifetime of 2 h (not shown). We found that the number of cells tracked by tobac decreased significantly. The CONFIG file for running CoCoMET is available in .