Running MET verification
in the browser

The idea in one breath

Strip away the file formats and orchestration, and MET's gridded verification is three operators wrapped around arithmetic: interpolate forecast onto the observation geometry, threshold + mask, then accumulate partial sums and contingency counts — from which every published score is simple algebra. The accumulation and algebra are cheap; a browser does them instantly. The only genuinely hard part — decoding GRIB2 / prepBUFR — is done once, offline, exactly as MET's own pb2nc / regrid_data_plane do it before verification runs.

The pipeline, step by step

Click any step to open its detail. Green = runs in the browser (and is proven live against MET); amber = reachable but heavy or data-gated; orange = must be pre-processed offline first.

Benchmarks — does it actually scale?

The same kernel the explorer runs, measured on synthetic grids from the real case size (8k cells) up to 2048² (4.2 M cells). Single-threaded JavaScript, no WASM or GPU.

Numbers

Cold start — a fresh tab, an empty cache

The numbers above are warm (steady state, after the JS engine has compiled the hot path). What a colleague actually feels on their very first click is the cold column — the first call before V8 optimizes. It settles to the warm number within a few interactions.

Taking FSS to the GPU

Step 6 (the neighborhood / Fractions Skill Score) is the one operator with no closed form over partial sums — it needs a sliding window over the whole grid, which makes it the natural GPU target. It's now built four ways as real WebGPU compute kernels, each parity-checked against the CPU integral image (scored-center counts exact, FSS within ~2×10⁻⁸). Try it live: WebGPU FSS.

The four kernels trade simplicity for scaling, and the right choice depends on the neighborhood radius r and the grid size:

• Naive — one thread per cell sums its full (2r+1)² window. Dead simple, O(cells·r²): wins at small r by sheer parallelism, but its work grows with r².
• Separable — factor the 2-D box into a horizontal then a vertical 1-D sliding-window pass. O(cells), independent of r — stays flat as the window grows, but each line's running sum is serial (one thread per line).
• Prefix-scan — build an integral image on the GPU with a workgroup shared-memory block scan (Hillis-Steele), then answer each cell with four O(1) lookups. Also O(cells), and by removing the separable kernel's serial per-line dependency it ends up the fastest at large r — but one workgroup handles one line, so a line can't exceed 2048 cells.
• Multi-block — the same integral image, but each line is split into 2048-cell blocks scanned in parallel, then a second pass scans the per-line block totals and a third adds the offsets back. This lifts the single-workgroup line limit so the scan scales to any real grid, at the cost of a more complex kernel.

The r-sweep — where algorithm beats brute force

Fixed 1024² grid (1.05 M cells), growing the neighborhood. Apple M2 Pro. Warm median ms.

Beyond one workgroup — the multi-block scan

The prefix-scan kernel scans each line with a single workgroup (256 threads × 8 elements = 2048 cells), so a line longer than 2048 has nowhere to go. The multi-block scan removes that ceiling with the textbook three-phase parallel prefix: every 2048-cell block scans itself and emits its total; one pass exclusive-scans the per-line block totals into offsets; a final pass adds each block's offset back. Run for rows then columns, it builds the full 2-D summed-area table for arbitrarily long lines. Verified live on grids the single-block kernel can't touch — 3072² (9.4 M cells) and 8000×1024 (four blocks per line) — still bit-for-bit with the CPU (n exact, FSS Δ ~10⁻⁹).

A GPU portability trap worth knowing

GPU → screen, no readback

The fraction fields the FSS compares are also rendered end-to-end on the GPU, from the same integral image the scan kernel builds: a compute pass runs the multi-block SAT scan, a colorize pass box-queries it (four O(1) lookups per cell) and writes the colormap straight into a texture, and a render pass samples that texture onto the canvas — nothing is copied back to JavaScript. The scan source is literally shared — one WGSL fragment is included by both the scoring kernel and the renderer — so the map and the score are one integral image, not two implementations. The whole scan → box-query → colormap → pixels path stays on the device (~1 ms/frame), the shape of a real interactive verification map.

The trade-offs — pros, cons, benchmarks

Five levels of the same score, each a point on the effort-vs-payoff curve. Pros and cons sit side by side; switch to benchmarks (warm-median ms at 1024² on the Apple M2 Pro, measured in the live app).

A global-capable store where most models are regional-only

To score any model live in the browser, we put every model on one common grid and make model a dimension. But models don't all cover the same ground: AIGFS and GFS are global, while a mesoscale WRF or 4DWX run covers only a small region. Naïvely, a shared grid means every regional model pays for the whole continent in empty cells. Two Zarr properties make that not so — and the same idea scales the store from one region up to the planet.

First, missing data is stored as an ordered sentinel (1e30), and a chunk that's entirely sentinel either isn't written at all or compresses to almost nothing. So a regional model in the shared model dimension costs storage proportional to its footprint, not the full grid. Second, a multiscale pyramid lets each model live at its honest resolution — global models on a coarse global level, regional models on a fine regional level — so a coarse 0.25° model is never blown up to 2.5 km just to sit in the same store.

Toggle models and switch the storage strategy — watch what each one actually costs. (Tile counts and sizes are illustrative but track the real design ratios.)

What this means for MET users

• The verification math is portable. Every continuous and categorical score MET publishes is a function of a handful of accumulators — reproduced here to the 5th–6th decimal, with contingency counts bit-identical. No server round-trip, no install, no upload.
• The bottleneck is I/O, not compute. GRIB2 and prepBUFR decoding stay offline (heavyweight, format-heavy). Everything downstream — regrid, threshold, accumulate, derive, FSS — is browser-native once the data is in Zarr v3 / Parquet.
• It scales to operational grids. A 1024² field verifies in tens of milliseconds; 4 million cells in well under a second — single-threaded. The neighborhood/FSS operator is the natural next target for WebGPU / WGSL, where a grid-parallel convolution would leave the CPU far behind.
• Validation is built in. Because the browser can hold both the input and MET's ground-truth .stat, every stage is checked against the operational answer as it computes — the ultimate provenance.