Medium-Range Weather Forecast

Medium-range weather forecasting — predicting the global atmosphere out to ten days — was long the exclusive domain of physics-based numerical models running on supercomputers. ML-based forecasting has recently become competitive, but building such a model from scratch is genuinely hard: the atmosphere is chaotic, so skill decays rapidly with lead time; the model must stay physically coherent across a full latitude–longitude grid; and small errors compound when a model is rolled forward through many autoregressive steps.

This task distills the problem into the WeatherBench-2 evaluation conventions on ERA5 reanalysis data: from one gridded initial state, forecast nine standard channels — geopotential and temperature at pressure levels, surface temperature and winds, sea-level pressure, and humidity — at twenty lead times from 12 to 240 hours, on a single mid-range GPU and a fixed time budget.

Build a deterministic global weather model that forecasts all required atmospheric channels and lead times from a gridded initial state, and package it as a replayable deliverable at /app/weather_model/ containing predict.py, model.py, run_summary.json, and exactly one checkpoint file under checkpoint/.

• predict.py is invoked with --data-dir, --checkpoint, and --output-path, and must write one NPZ archive with exactly four arrays: init_times, lead_hours, channels, and finite float32 predictions of shape (N, 20, 9, lat, lon).
• The nine channels (z500, z850, t500, t850, t2m, u10, v10, msl, q700) and the twenty 12-hourly lead times from 12 to 240 hours are fixed by the contract.
• Forecasts must be deterministic and use no internet or external services; a full batch must complete within 30 minutes and a small batch within 10 minutes.
• The complete weather_model directory must be smaller than 2.5 GB and contain no symbolic links.
• Validation RMSE on the provided splits is the development metric; /app/validate_forecast.py checks an archive against the output contract locally.

ERA5-derived reanalysis data under /data in training and validation splits: each split has an init_index.parquet of initialization times, an init_states.zarr of gridded atmospheric states with axis order (channel, lat, lon), and targets.npz with the matching future states; metadata.json defines the grid and channel metadata. A starter scaffold lives at /app/weather_model/ alongside the contract documentation and the local forecast validator. The preinstalled pinned stack includes torch 2.6.0 (CUDA), numpy, pandas, zarr, xarray, scipy, and pyarrow, with one L4 GPU for training. The machine is offline; a sandbox-timer CLI reports the remaining budget.

A root-only clean-room verifier evaluates the submission on sealed, held-out ERA5 campaigns — multiple later temporal blocks never seen by the agent, integrity-checked file-by-file against a signed manifest. It freezes the deliverable read-only, revokes the agent user's access to the visible labeled data, and runs predict.pyas the unprivileged agent user three times: a primary full batch (30-minute cap), a deterministic replay of a sealed probe subset (10-minute cap) that must match the primary forecasts within a strict float32 tolerance, and a physically perturbed probe whose forecasts must actually change — defeating lookup tables and input-ignoring models.

• Skill is measured per channel and lead cohort (early 12–72 h, middle 84–168 h, late 180–240 h) using latitude-weighted anomaly correlation (ACC) against climatology and latitude-weighted RMSE.
• Each metric is normalized against sealed anchors — a baseline maps to 0, a calibrated reference forecast to 0.5, and the ideal to 1 — then combined as a weighted mean across fields and campaigns.
• Contract and safeguard gates are binary: any output-format violation, nondeterministic replay, insensitivity to perturbations, oversized deliverable, or failed run zeroes the result.