Arwen Global

A hydrostatic global spectral weather model that runs a whole forecast day on one consumer graphics card, with its own ensemble data assimilation.

Arwen Global integrates the moist primitive equations on a Gaussian grid in spherical-harmonic space, on a two-time-level semi-Lagrangian semi-implicit core at a 300 s step, with a full GPU physics suite (RRTMGP radiation, Morrison microphysics, Grell-Freitas or New Tiedtke convection, YSU boundary layer, Noah land, MM5 surface layer) on a 52 to 25 km grid at 40 hybrid levels. It cold-starts from a single public GDAS analysis, writes render-ready wrfout tapes that the same Rust renderer draws as every other ArWen product, and can run its own analysis cycle: a 32-member LETKF under the forecast control, fed by surface observations, radiosondes, buoys, satellite motion vectors and radio occultations through Rust decoders, with infrared and microwave radiance operators beside them. At 52 km a 24 hour global forecast takes about four minutes on a 16 GB card, and at 25 km about sixteen minutes on a 32 GB one. Every number on this page was measured; each one carries the card and the date.

This is an experimental research model. Its configuration surface can move between releases and its output is not a supported product. The claims it does not make are listed in docs/ARWEN_GLOBAL_FULL.md.

Install

pip install "gpuwm-global[gpu-cu13]"     # a CUDA 13 runtime
pip install "gpuwm-global[gpu-cu12]"     # a CUDA 12 runtime

One extra per CUDA major, because no pip environment marker can tell them apart. gpu-cu13 pulls cupy-cuda13x[ctk], gpu-cu12 pulls cupy-cuda12x[ctk], and the bare gpu alias is gpu-cu13, the stack the card figures on this page came off. Either line also resolves the engine gpuwm>=2.7.0,<2.8, its data companion gpuwm-data beside it, numpy, scipy and netCDF4. That range resolves gpuwm 2.7.3 and gpuwm-data 2.7.3 from the public index today. All four versions the index carries read the same at the boundary: 2.7.0, 2.7.1 and 2.7.2 were installed on the Windows desktop 2026-09-10 into virtual environments created from scratch, and 2.7.3, which the index published on 2026-09-12, was measured there the same day, where python tools/measure_boundary.py reads the same 231 symbols across 65 modules with no gap among the 191 a host without a CUDA runtime can resolve. The engine seam is pinned against 2.7.3, the version the range resolves today; the paragraph below this block says what moved to get there. Without either extra the package installs and every CPU door runs; the forecast needs the card.

No published engine produced the forecast and assimilation figures further down this page. They were taken on 2026-09-06 and 2026-09-07 in the engine checkout this model was developed and graded in, whose own version string reads 2.6.4, and no published 2.7.x carries the physics those runs integrated. That physics is what arwen_global.core carries now, which is why a bare install on any 2.7.x engine integrates the same bytes those runs did.

The Rust binaries the model calls at run time arrive as release assets, verified against the size and SHA-256 pins inside the wheel before they are used, never from a local cargo build:

gpuwm fetch-bridges        # the engine's own bundle
gpuwm-global fetch-doors   # the eight observation binaries only this package publishes
gpuwm-global doctor        # what is installed, staged and missing

doctor exits 1 while any boundary gap stands, and every line that says no names the command it stops and the remedy. Two gaps stand on every published 2.7: preflight.measured_free_vram_bytes and surface_bias.interpolate_to_tape are absent from 2.7.0, 2.7.1 and 2.7.2 (read on the Windows desktop 2026-09-10) and from 2.7.3 (read there 2026-09-12), so a correct install of this release exits 1 as well. Neither stops a command this page or docs/CLI-REFERENCE.md documents: the first stops the standalone card-pricing check that no subcommand is wired to, and the second the surface-energy scorecard's regrid onto the tape. Read the section bodies for install health, not the exit code.

gpuwm-global needs gpuwm>=2.7.0,<2.8. The ceiling is not decoration: the engine's own trees are not supersets of each other across minors, and this package imports 231 symbols across that boundary. python tools/measure_boundary.py regenerates the measurement rather than trusting a table, and names the symbols it could not check on a host without a CUDA runtime instead of counting them clean. The physics the model was graded with is INSIDE this package (arwen_global.core: the radiation, cumulus, surface-layer, boundary-layer, land-surface and microphysics schemes, their kernels, the CUDA loader, the float64 mirror the scorecards grade against and the Noah tables), so any 2.7.x engine integrates the same bytes the grading tree did. The engine files the carried code still reaches are pinned by path, size and SHA-256 in arwen_global/data/engine-seam.json, and gpuwm-global doctor re-hashes them and prints an engine seam section: 46 of 46 files proven against gpuwm 2.7.3 on this desktop, 2026-09-12, which is what a fresh install of this release resolves.

The pins hold one version at a time, and they were moved from 2.7.0 to 2.7.3 after the eight files 2.7.3 changed were read hunk by hunk: config.py, core/state.py, core/preflight.py, physics_compat.py, physics_vertical_contract.py, core/microphysics.py, core/refl.py and core/rrtmg_legacy.py. Every symbol this package imports out of those eight is byte-identical between the two engines except three, and all three are prose or a widened acceptance rather than a different number: RunConfig and DomainState moved in comments only, with no field, default or validation changed, and radiation_scheme_ids narrowed a refusal so that writing ra_physics=4 beside ra_lw_physics=4/ra_sw_physics=4 resolves to the same (4, 4) pair instead of raising. The scratch arena now accepts a same-width dtype it used to reject, and the microphysics ring-guard family grew ten scheme-native names behind a presence guard on a path no door of this package enters. tools/measure_boundary.py and tools/measure_engine_signatures.py read the same 231 symbols and the same 28 signature rows on 2.7.3 as on 2.7.2, with no new gap. The two nodes of tests/test_arwen_global_engine_seam.py that compare hashes now run against the pinned version and skip, naming both versions, on any other published 2.7; a file whose bytes moved is reported by name as unproven, and the version ceiling is the refusal. Where the carried physics differs from the engine's own copy of the same file, and whether a future engine change to that code should be taken, refused or offered back, is one row per difference in docs/CARRIED-PHYSICS-DIVERGENCE.md, held to the installed engine by tests/test_engine_divergence.py, which is baselined on 2.7.3 and skips its two comparisons on any other.

A forecast day, in one command

gpuwm-global go arwen_global_gdas_t255_native_sl_si_24h \
    --outdir out/day --start-date 2026-09-01_00:00:00

That builds the static surface fields, integrates the forecast, exports render-ready tapes and draws the product pictures, naming the stage it is in while the detail goes to the run's log.

Fifty-five experiments ship inside the package and resolve by bare name from any directory (gpuwm-global configs lists them); a path that exists always wins over a shipped name, so an edited copy runs.

The same day, one stage at a time

1. Fetch the analysis. One whole-globe GDAS object, about 500 MB, no credentials.

gpuwm fetch --source gdas --cycle 2026-09-01T00 --hours 0 \
  --mode full-file --out cases/baseline-2026090100

--hours 0 takes the f000 analysis alone, which for GDAS is the assimilation cycle's own estimate of the atmosphere rather than a forecast field. --mode full-file takes the whole globe: the default GDAS transport is an area crop, and the initializer refuses a longitude ring that does not close.

2. Build the surface statics, once per truncation, from the geography archive.

gpuwm-global statics arwen_global_gdas_t255_native_sl_si_24h --geog-root ~/WPS_GEOG

3. Run the day. Nothing about memory is set: the door prices the card, chooses the latitude band count and decides which state slices to park on the host, and refuses before it allocates anything if the card cannot hold the run.

gpuwm-global run arwen_global_gdas_t255_native_sl_si_24h --outdir out/t255-day

288 whole steps at 300 s, a checkpoint every three hours, diagnostics.jsonl and a self-hashed receipt beside them. gpuwm-global check-receipt validates the receipt; --restart continues from a checkpoint.

4. Draw it.

gpuwm-global render out/t255-day \
  --outdir out/pictures --start-date 2026-09-01_00:00:00 \
  --products 2m_temperature,mslp_10m_winds,500mb_height_winds

render takes checkpoints, a whole run directory or tapes that are already exported; it writes the intermediate tapes itself and removes them unless --keep-tapes is given. No experiment is named on that line because run and go leave a byte copy of the config beside their checkpoints, so a run directory says what made it; --config states it for inputs that are not in one. gpuwm render TAPE --list-products prints the catalogue and says which entries a given tape can actually fill. The tapes carry MAP_PROJ = 6, so global frames go out through the ordinary layout, <outdir>/<domain>/<product>/<valid-day>/. Weather fields are drawn by the Rust renderer rw_wrfbatch and by nothing else. gpuwm-global export writes the tapes without drawing them.

No card? arwen_global_moist_smoke is a T3 four-step numpy run that goes through the identical run, export and render sequence in seconds and produces a real global frame. It rehearses the plumbing, not the forecast.

A fresh global analysis

gpuwm-global da fresh arwen_global_gdas_t255_native_sl_si_24h \
  --outdir out/fresh --stream iem-asos --filter letkf --members 32

da fresh fetches the newest GDAS analysis, derives its run configuration from the base experiment named on the line, builds the ensemble if the output directory has none, cycles hourly to the newest observation hour, and hands back the analysis checkpoint. At least one observation source is required and named: --stream fetches a stream for every window, --obs reads a table already on disk, and both repeat. Without --filter letkf the analysis is the deterministic successive correction with a single member, which is the shipped default.

The receipt out/fresh/da-receipt.json names the analysis checkpoint it handed back and carries forecast_command, the exact line that forecasts from it:

gpuwm-global da forecast out/fresh/fresh-config.toml \
  --analysis out/fresh/arwen_global_analysis_step00000036.npz \
  --outdir out/fresh/forecast

The forecast runs to the derived configuration's duration, which is the cycle span plus --forecast-hours (24 by default); --until-s stops it earlier. The legs are separately reachable: da init builds the ensemble, da cycle runs the hourly windows over named streams, da analyze analyses one instant. Every analysis writes a report with the observation counts, the quality-control rejections by name, the o-minus-b and o-minus-a fits by stream and variable, and the Desroziers diagnostics.

gpuwm-global obs streams prints the ten observation streams with the Rust door each one decodes through, whether that decoder is built, and its measured latency behind real time; gpuwm-global obs fetch writes a stream's table to disk for --obs.

What the cycle is worth, measured. Six hourly LETKF cycles from the GDAS 2026-08-31 18Z analysis, 32 T127 members under a T255 control, METAR, IGRA2, NDBC and GOES derived motion winds, 879,488 rows offered over the six windows: the METAR surface-pressure o-minus-b grew from 115 to 158 Pa across the six hours while the o-minus-a held at 76 to 82 Pa (MEASURED 2026-09-06). Scored at the stations against the GDAS analysis of the same instant, the handed-back analysis reads 2 m temperature +0.45 / 2.10 K against GDAS's -0.35 / 2.35, 2 m dewpoint +0.16 / 2.60 against -2.53 / 4.10, mean sea level pressure -1.05 / 2.44 hPa against -1.68 / 2.79, and 10 m wind 2.05 against 1.91 m/s, on a common set of 1,591 stations; at the soundings it is worse than the GDAS analysis on every row (MEASURED 2026-09-06). The system ships selectable, not default: the cycle beats the analysis it started from at the surface and does not reach it aloft, and the door says so.

The analysis runs on the card. The analysis proper (the step less the members' forecast hour and the control re-integration) costs 26.4 s on an RTX 5090, against 185.8 s on the host path, and the whole hourly cycle costs 390.5 s, so a cycle keeps up with the hour it covers by a factor of eight (MEASURED 2026-09-07).

The quickstart itself, run from the installed wheel. Three hourly cycles from the GDAS 2026-09-01 00Z analysis over the public surface stream on the shipped deterministic filter, on an RTX 5070 Ti shared with another job: status pass, three of three cycles engineering-complete, 596.5 s for the whole command, 76.1 s a cycle on average and 89.6 s at worst, which is 0.025 of the hour each cycle covers. At the third analysis 20,713 rows were assimilated and 2,302 withheld from it for the gate of record. Station pressure read 403.2 Pa o-minus-b against 113.2 o-minus-a on 4,519 rows, temperature 1.946 against 1.816 K on 4,717, and the wind components 2.157 against 2.047 and 2.156 against 2.085 m/s. Dewpoint read 3.383 against 3.411, worse after the analysis than before it, and the door printed that as a reading rather than hiding it: --moisture-update is off by default, so dewpoint rows are scored and not analysed (MEASURED 2026-09-07).

What it runs on

A 24 hour forecast, 288 steps at 300 s on the shipped semi-Lagrangian core, the full native physics suite, 40 hybrid levels, float32. Wall clock is end to end from each run's own receipt. "Shared" means another process held the card, so the row is a capability row rather than a timing.

Every row was measured on the date in its last column, in the engine checkout this model was developed and graded in, whose version string reads 2.6.4. No published engine produced them. The physics those runs integrated is carried inside this package as arwen_global.core, so a bare install on any 2.7.x engine integrates the same bytes; what the published 2.7.0, 2.7.1 and 2.7.2 were measured for is the boundary reading, the engine seam and the source mappings, all read on 2026-09-10, and 2.7.3 for the boundary reading and the carried-physics rows, read on 2026-09-12.

At the same truncation on the same tree, the selectable Eulerian core imex_ssp3 takes 1,099.3 s for the T255 day at a 60 s step and 1,050.2 s at its shipped 90 s step on the RTX 5070 Ti (MEASURED 2026-09-06 and 2026-09-07). A 300 s semi-Lagrangian step costs about one Eulerian step, so the day is 288 steps instead of 960.

The card is priced, not guessed. run estimates the device peak, weighs it against free VRAM, chooses the latitude band count and the host tier, and refuses a plan that will not fit, naming which allocation dies first. Across seventeen legs with a card reading, the gate was on the refusing side every time, the tightest by 0.047 GiB (MEASURED 2026-09-06). Where a completed run of a lighter plan bounds a heavier one, the door prices at that measurement instead of at its model, and the receipt names the run that bounded it.

Banding does not move a bit. The physics suite runs a latitude band at a time, and the ten-step T255 gate of record is byte-identical between one band and eight: 309 of 309 checkpoint arrays, on both cards (MEASURED 2026-09-07). The host tier is the same: 442 of 442 checkpoint arrays byte-identical with the tier off against on (MEASURED 2026-09-07). The banded transforms are exact too: 93 of 93 FFT cases bit-exact at 0 ULP across T255, T383 and T533 crossed with band counts 2 to 32, and 892 of 892 waist comparisons bit-exact on each card (MEASURED 2026-09-06).

The doors

One console script, 48 commands. gpuwm-global <command> --help prints every option; docs/CLI-REFERENCE.md is the same surface on one page, generated from the parser.

run, go, render and run-plan write status.json into their output directory, rewritten atomically at each stage and at each step, and an append-only log beside it: these are the four long-running doors, and a workspace driving one of them reads its stage, its progress and its ending from that file rather than by scraping a growing console. The shorter commands print their answer and are read by watching stdout. Exit codes are 0 success, 1 a refusal that names its reason, 2 an argument error, 3 a Rust door missing or failing its pin, 4 the device declining admission. Every finished run leaves a self-hashed receipt carrying the configuration identity, the arithmetic pins, the library versions the numbers rode on, the engine version and the staged binary digests, so a run can be compared to a configuration without opening a checkpoint.

Driving it from a program

A desktop application, a terminal workspace or a CI job drives this model through the same versioned contract the engine publishes, so a client written for gpuwm drives gpuwm-global by changing the module it spawns.

gpuwm-global sources --json                          # gpuwm.run-plan.sources.v1
gpuwm-global run-plan --catalog                      # gpuwm.run-plan.catalog.v1
gpuwm-global run-plan --physics-profiles             # gpuwm.run-plan.physics-profiles.v1
gpuwm-global run-plan --probe --no-readiness         # gpuwm.run-plan.probe.v1
gpuwm-global run-plan plan.json --resolve            # gpuwm.run-plan.resolved.v1
gpuwm-global run-plan plan.json --estimate           # gpuwm.run-plan.estimate.v1
gpuwm-global run-plan plan.json                      # execute; events on stdout

A plan is a gpuwm.run-plan.v1 envelope over an experiment TOML, and config.path takes a shipped experiment's bare name. A run writes run-manifest.json, run-progress.json and events.jsonl beside the status.json above, all three in the engine's own schemas, so a client reattaches to a run of this model with the reader it already has. python -P -m arwen_global.tui_worker --job-dir DIR -- <args> is the same durable handshake as gpuwm.tui_worker for a detached job.

docs/ARWEN_GLOBAL_CLIENT.md is the whole contract, including what the engine offers that this package does not and why.

What it looks like

These came out of the installed package on an RTX 5070 Ti: a 24 hour forecast from the public GDAS 2026-09-01 00Z analysis at T255, valid 2026-09-02 00Z, exported to wrfout tapes and drawn by the Rust renderer. Eight products at nine forecast hours, 72 pictures; four of them here, the rest with their captions in docs/demo/CAPTIONS.md.

Precipitable water. The intertropical convergence zone, the monsoon over the Bay of Bengal and the South China Sea, mid-latitude moisture plumes, and the dry subtropical highs and Antarctic.	500 hPa height and wind. The austral winter jet runs unbroken around the Southern Ocean at over 70 m/s; the northern jet is weaker and split, with closed lows over Siberia and the North Pacific and 594 dam ridges over both ocean basins.
Mean sea level pressure and 10 m wind. The Southern Ocean storm belt carries lows at 949.9 and 961.5 hPa; tropical cyclones sit in the west Pacific and the Indian Ocean; the subtropical highs close at 1030 hPa.	2 m temperature. Late northern summer over the continents, the Sahara and Arabia at their hottest, the Antarctic plateau at its coldest, and the Andes and Himalaya drawn by their own orography.

And the analysis cycle draws the same way. This is the state the three-cycle quickstart above handed back, 2 m temperature valid 2026-09-01 03Z, exported and drawn by gpuwm-global in one command:

The mean sea level pressure picture that same run drew at its own step 0 is byte-identical to the forecast demo's, md5 b772960e…, from a different run on a different day through a different export and a different render call (MEASURED 2026-09-07).

Where things come from

• The engine. gpuwm supplies the GRIB2 source decoder, the observation front door, the static-field builder, the LETKF filter core, the wrfout writer, the physics tables and the renderer. This package supplies the spectral core, the global dynamics, the global physics registry, the global data assimilation and the doors.
• Every data path is Rust. GRIB decode, NetCDF read and write, observation decoding, regridding and rendering run in Rust binaries the engine stages; Python is the command line and the CUDA driver code. The binaries arrive as release assets and are verified by size, SHA-256 and a contract marker before they are used.
• The observation doors the assimilation calls are rw_asos (surface networks), rw_igra2 (radiosondes), rw_ndbc (buoys), rw_amv (satellite motion vectors), rw_gnssro (radio occultation), rw_wis2 (the WMO information system), rw_goes (ABI) and rw_atms (microwave).
• Statics come from the public geography archive through the engine, cached once per truncation.

Documentation

Licence

Apache-2.0. See LICENSE and NOTICE.