Adding in optional tooling for AI detection models

[aaTman]

There's a few models in the literature, and bound to be more in time, that are built to detect extreme events. Some of these examples are:

Click to expand

Foundational / segmentation datasets & architectures

• Mudigonda et al. (2017), "Application of Deep Convolutional Neural Networks for Detecting Extreme Weather in Climate Datasets," arXiv:1605.01156 — earliest DL extreme-event detector; CNN classifier for TCs, ARs, and weather fronts simultaneously (89–99% accuracy)
• Prabhat, Kashinath, Mudigonda et al. (2021), "ClimateNet: an expert-labeled open dataset and deep learning architecture for enabling high-precision analyses of extreme weather," Geosci. Model Dev. — introduces the expert-labeled TC/AR segmentation dataset and DeepLabv3+-based architecture. DOI: 10.5194/gmd-14-107-2021
• Kapp-Schwoerer et al. (2020) — improved segmentation of TCs/ARs building on ClimateNet, context aggregation network variants
• "Improving extreme weather events detection with light-weight neural networks," arXiv:2304.00176 — lightweight CGNet architecture applied to the ClimateNet TC/AR segmentation task

Newer/expanded datasets

• ClimateNetLarge (2025), "A large-scale dataset for training deep learning segmentation and tracking of extreme weather," Scientific Data — expands to ARs, TCs, and atmospheric blocking; ~49,000 hand-labeled ERA5 timesteps. DOI: 10.1038/s41597-025-05480-0

Front detection

• "Machine Learning-Based Detection of Weather Fronts and Associated Extreme Precipitation in Historical and Future Climates" — DL front detector plus precipitation-extremes analysis
• Parfitt, Czaja & Seo (2017), "A simple diagnostic for the detection of atmospheric fronts," GRL — traditional-method baseline commonly benchmarked against

AR-specific ML detection

• Chapman et al. (2019), "Improving Atmospheric River Forecasts With Machine Learning," GRL

It could be useful to have an optional abstraction layer in EWB that can use these models, assuming they use a unified format we can pipe in. Something like:

import extremeweatherbench as ewb

blocking_model = ewb.derived.load_model('/path/to/model.pth')

Where blocking_model is a DerivedModelObject that builds in the required variables to feed into the model into its metadata, then:

case_yaml = ewb.cases.load_cases()

# ERA5 target
era5_target = ewb.inputs.ERA5(
    variables=[blocking_model]
)

grap_forecast = ewb.inputs.get_cira_icechunk(
    model_name="GRAP_v100_GFS",
    variables=[blocking_model],
    name="Graphcast"
)

blocking_evaluation_objects = [
    ewb.inputs.EvaluationObject(
        event_type="blocking",
        metric_list=[
            ewb.metrics.CriticalSuccessIndex(),
            ewb.metrics.EarlySignal(),
            ewb.metrics.SpatialDisplacement(),
        ],
        target=era5_target,
        forecast=grap_forecast,
    ),
]

blocking_ewb = ewb.evaluate.ExtremeWeatherBench(
    case_metadata=case_yaml,
    evaluation_objects=blocking_evaluation_objects,
)
outputs = blocking_ewb.run_evaluation(parallel_config={"backend": "loky", "n_jobs": 3})

The internals catch that the variable is the .pth model with associated variables required to predict, runs inference on the forecast data, and produces the new variable dataset for (in this case) atmospheric blocks.

We could add this as an optional component given the increase in dependencies something like pytorch would bring; that said, it'd be a cool way to help unify federated approaches to forecast verification.

[linear-code]

EWB-102