Climate & earth-system modelling

Physics-based climate and earth-system models need supercomputers and weeks of runtime per scenario. Machine-learning emulators, hybrid physics-ML models and learned downscalers reproduce key behaviour orders of magnitude faster, allowing larger ensembles, finer resolution and quicker what-if analysis. They complement, not replace, physical models, and their main risk is reliability outside the training distribution.

Problem & value

• Today: global and regional climate models (e.g. ICON, IFS, EC-Earth, NEMO, regional CORDEX models) run on HPC systems. Cost limits ensemble size, resolution and the number of scenarios. Downstream users (cities, utilities, insurers) typically get coarse data or pre-computed products.
• AI value: fast emulators for ensembles and tail-risk sampling, statistical/generative downscaling from ~100 km to km-scale, bias correction, parameterisation learning (clouds, convection), and automated evaluation of model output against observations.
• Evidence: ML weather models (GraphCast, Pangu-Weather, ECMWF AIFS) match or beat physics-based medium-range forecasts on many headline scores at a fraction of the compute for inference [1][2]. For climate timescales, hybrid models such as NeuralGCM show multi-decade stability for some configurations, but evidence is much thinner than for weather [3].
• Policy context: the EU Destination Earth (DestinE) initiative builds digital twins of the earth system with km-scale ambitions, creating public demand for AI-accelerated components [4].

Variants

• Weather-to-subseasonal ML models: data-driven forecasting as a building block (see PRED-017).
• Climate emulators: fast surrogates of a specific CMIP6 model for scenario exploration (e.g. ClimateBench-style tasks).
• Hybrid physics-ML GCMs: differentiable dynamical core plus learned physics (NeuralGCM).
• Downscaling & bias correction: statistical, GAN/diffusion-based; used for regional impact studies (see PRED-036).
• Ocean, cryosphere, land and carbon-cycle emulators.
• Agentic evaluation: LLM agents that script analysis of climate data (xarray, CDO), a research-assistant use (see SCI-011).
• Private use: none beyond consumption of published forecasts and climate atlases.

How it works

1. observations + reanalysis (ERA5) + CMIP6/CORDEX output
2. data curation & regridding (xarray, Zarr, intake-esm)
3. model: emulator / hybrid GCM / diffusion downscaler (trained on physics-model or reanalysis data)
4. autoregressive rollout or conditional sampling
5. ensemble
6. physical-consistency checks (conservation, spectra, extremes, drift)
7. evaluation vs. reference models and observations
8. scientist review
9. publication / downstream impact models

• Architectures: graph neural networks (GraphCast, AIFS), transformers (Pangu, Aurora), neural operators (FourCastNet), diffusion models for ensembles and downscaling, hybrid differentiable solvers.
• Foundation models: pretrained on large reanalysis/model archives and fine-tuned per task (e.g. Microsoft Aurora, Prithvi-weather and Prithvi-EO from NASA/IBM) [5].
• Human-in-the-loop: climate scientists validate physical plausibility, long-term drift and extremes before results enter any assessment or product. Uncertainty communication is mandatory.

Data preparation

Needed data are reanalysis products (e.g. ERA5), model output (CMIP/CORDEX), station and satellite observations, and for risk teams exposure data such as asset locations. They live in archives such as Copernicus data stores, HPC file systems, institute file shares and in-house databases. Typical gaps: heterogeneous formats and grids (NetCDF, GRIB, Zarr), inconsistent units and calendars, missing or biased station records, undocumented model versions, large volumes that do not fit on a laptop, and exposure data of poor quality.

Preparation steps: inventory sources and map them to the model inputs (PREP-001, PREP-002); convert to analysis-ready, chunked cloud-native formats (Zarr) with standard metadata; regrid and bias-correct; build train, validation and test splits by time period to avoid leakage; clean exposure tables (PREP-011); document variables in a glossary (PREP-012). Tools: xarray, Dask, CDO, Intake catalogues. Expect about half to two thirds of the effort in data engineering. See GUIDE-003.

Implementation paths

Which path for whom

• Enterprise (climate-risk, energy, insurance teams): Path C. Open pretrained emulators and downscaling models run on own GPU nodes, and the risk models are core know-how that should not depend on a vendor.
• Developer: Path C. Open weights and frameworks (e.g. Earth2Studio, GraphCast-style models) allow fine-tuning and reproducible experiments.
• Public (met services, research institutes): Path C. HPC centres and sovereign infrastructure are already available, and publicly funded science favours open, auditable models.

Path A — Buy (off-the-shelf)

Mostly consumption of services rather than model building: Copernicus Climate Data Store and Climate Change Service (EU), DestinE data portal (EU), ECMWF open data, plus commercial climate-analytics vendors for downscaled indicators, e.g. Jupiter Intelligence, Climate X (check provenance and validation; Cervest went into administration in 2023 and its assets were sold, so do not rely on it). For SMBs and municipalities this is the right path.

Path B — Build on cloud APIs

• Hosted inference of pretrained models: Microsoft Aurora via Azure AI Foundry, NVIDIA Earth-2 (cloud/NIM microservices), Google weather/NeuralGCM-related releases where available, ECMWF AIFS via open data.
• Cloud-native data: Copernicus DIAS platforms (EU, e.g. CREODIAS, WEkEO), Planetary-Computer-style Zarr catalogues.
• LLM assistants (Claude, Mistral, Gemini) for generating analysis code, with outputs reviewed by scientists.

Path C — Self-host (open source)

• Models: ECMWF AIFS (open weights, anemoi framework), NVIDIA Earth-2 / earth2studio, FourCastNet, GraphCast (open code/weights, check licence), Pangu-Weather, Aurora (open weights), NeuralGCM (open code), Prithvi (open).
• Stack: PyTorch, JAX, anemoi, xarray, Dask, Zarr, ESMValTool for evaluation, Climate Data Operators (CDO).
• Hardware: inference of 0.25° global models fits one HW3 GPU; training and km-scale work need HW4-HW5 or EuroHPC systems (e.g. LUMI, Leonardo, JUPITER) via access calls.

Path D — Custom training

Needed for a specific region, variable or model emulator. Requires terabytes to petabytes of simulation or reanalysis data, GPU cluster time and domain experts. Usually run as a research project with a national weather service or institute.

State of the art (2026)

• Data-driven global forecasting is operational at ECMWF (AIFS, including ensemble version) and other services, and is increasingly the base for DestinE work [2][4].
• Generative models give calibrated ensembles at low cost; km-scale ML downscaling is productive for temperature and precipitation but weaker for rare compound extremes.
• Hybrid models like NeuralGCM show promise for multi-decade climate runs; pure ML climate emulators are trusted mainly for interpolation within scenario ranges [3].
• Limits and failure modes: extrapolation to unseen warming levels, violation of conservation laws, drift in long rollouts, smoothed extremes, training-data bias (reanalysis errors), and weak causal fidelity for tipping elements. Benchmarks (WeatherBench 2) measure forecast skill, not climate-change fidelity [1].

Shared resources & combinations

• Same stack: PRED-017 (weather forecasting), PRED-027 (floods), SCI-005 (simulation surrogates) share models, GPU nodes and Zarr/xarray pipelines.
• Data side: VIS-021 and VIS-042 (satellite imagery, methane) supply observations; PRED-036 consumes downscaled hazard data; OPT-026 uses weather fields for routing.
• Agents: SCI-011 for automated analysis workflows.

Effort, cost & KPIs

• Path A/B: days to weeks; costs are data and API fees.
• Path C: 2-6 months to reproduce and validate a pretrained model locally; the main cost is GPU operation and staff.
• Path D: 1-3 years as a research programme; large compute budgets.
• KPIs: skill scores (RMSE, CRPS, spread-skill) against baselines, extreme-event capture, long-run drift, energy conservation error, speed-up versus physical model, reproducibility.

People & change

Start with management and the department lead to agree the scientific or business question, then involve scientists and analysts as end users, IT/HPC operations for compute and storage, the owners of observation and model archives, and suppliers of data products. Data protection plays a minor role because the data are mostly non-personal; involve the DPO only if exposure or address-level data appear (GUIDE-005).

Works council: usually no. The system analyses geophysical data, not employee behaviour or performance, so §87(1) no. 6 BetrVG is not triggered. Still inform the works council in good time under §90(1) no. 3 if work processes change noticeably; public institutes inform the staff council.

AI literacy: Art. 4 AI Act requires measures that support staff's AI literacy; run short workshops on what emulators can and cannot do, especially extremes and out-of-distribution behaviour (GUIDE-006). Pilot on one region and variable, benchmark against the physical model, and publish the validation. Typical concern: replacing physical models or trust in black boxes. Address it by positioning emulators as complements, running physics-based checks and keeping scientists responsible for results (GUIDE-009).

Risks, regulation & compliance

• EU AI Act: minimal risk for research and general climate modelling. If outputs feed safety components of critical infrastructure (Annex III), obligations may attach to the integrator. AI literacy (Art. 4) applies. General-purpose-model rules do not usually apply to domain models.
• GDPR: gridded geophysical data is not personal data; combine with address-level exposure data and it can become so (insurance, real estate).
• Data licences: ERA5 and CMIP6 terms (Copernicus licence, attribution); check weight licences (some non-commercial).
• Scientific integrity: do not present emulator output as a physical projection without validation; document uncertainty (IPCC practice). Disclosure duties may arise under CSRD/ESRS E1 climate-risk reporting when used for physical risk assessment.
• Mitigations: benchmark against physical models, keep a physics baseline, publish evaluation, version data and weights.

Getting started

1. Define the decision: forecast, scenario emulation, downscaling, or risk indicators.
2. Try existing Copernicus/DestinE products first before building a model.
3. Run a pretrained open model (AIFS, Earth-2, Aurora) on a small region and compare with ERA5.
4. Add evaluation with ESMValTool and extreme-event metrics; check drift on long rollouts.
5. For production use, agree validation criteria with domain scientists and apply for EuroHPC compute if training.

Sources

1. WeatherBench 2 benchmark — https://sites.research.google/weatherbench/
2. ECMWF — AIFS machine-learning forecasting — https://www.ecmwf.int/en/about/media-centre/aifs-blog
3. Kochkov et al., Neural general circulation models for weather and climate, Nature 2024 — https://www.nature.com/articles/s41586-024-07744-y
4. European Commission — Destination Earth — https://destination-earth.eu/
5. Bodnar et al., A foundation model for the Earth system (Aurora), Nature 2025 — https://www.nature.com/articles/s41586-025-09005-y
6. NVIDIA Earth-2 — https://www.nvidia.com/en-us/high-performance-computing/earth-2/
7. Copernicus Climate Change Service — https://climate.copernicus.eu/
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj