Input Data & Initialization

wrf_gpu keeps the WRF run artifacts you already know: namelist.input, wrfinput_*, and wrfbdy_d01. It integrates those real-data inputs on the GPU with no CPU-WRF wrfout dependency, and auto-detects a legacy replay path when CPU-WRF wrfout history is present.

Standalone native-init inputs¶

Operational The primary path is standalone native-init. The current CLI reads the model's initial state from wrfinput_<domain> and the root lateral-boundary forcing from wrfbdy_d01. There is no CPU-WRF wrfout replay in the loop; the forecast state is advanced by wrf_gpu on the GPU.

A standalone case directory looks like a normal WRF real-data case:

my_case/
├── namelist.input        # standard WRF v4 ARW namelist (bring your own)
├── wrfinput_d01          # initial state (one per domain you run)
├── wrfinput_d02
└── wrfbdy_d01            # lateral boundaries for the outer domain

You produce these with any standard WRF preprocessing chain (WPS + real.exe) or use a bundled case that already contains them. For a live-nested run (--max-dom N) the parent builds each child's lateral boundary live, so you only need a per-domain wrfinput_d0N and wrfbdy_d01 for the outer domain — no pre-supplied wrfbdy_d02. See Nesting.

Replay mode (auto-detected)¶

Legacy path When the case directory already contains CPU-WRF wrfout history files (≥ 2 wrfout_<domain> files), run auto-detects replay mode: it takes the initial state and boundaries from that existing CPU-WRF history rather than building them natively. It is an older comparison path; the release validation instead runs standalone forecasts from the same wrfinput and wrfbdy files as CPU-WRF.

Detection and the mode banner are described in Running the Model.

The role of namelist.input¶

Your namelist.input is the source of truth for the physics menu and many domain/output settings. The current CLI still uses a few explicit run-control flags, so it is not yet identical to wrf.exe's "just read the namelist" ergonomics. wrf_gpu reads the namelist directly:

• It is validated fail-closed before any compute: an unsupported scheme is refused with a named reason, never silently substituted (see Namelist Compatibility).
• &domains max_dom is read to know how many domains the case describes, but a nested run uses --domains-from-namelist or explicit --max-dom — a multi-domain namelist run without either nesting flag executes a single domain and prints a reminder.
• Native runs honor per-domain radt and cudt through integer step cadence. Other cadence approximations, when present, are named separately in the effective payload.

By default run uses <input-dir>/namelist.input; pass --namelist to point elsewhere.

Restart files¶

A WRF wrfrst file is not accepted as initialization. Native single-domain d01 and nested runs can resume from their own verified checkpoint generations (--resume-checkpoint); see Running → Restart.

What comes out¶

Initialization feeds the forecast, and the forecast writes a WRF-compatible wrfout NetCDF history file (plus a run-payload JSON) under --output-dir. Dimensions and variables match WRF's conventions; details and the variable subset are on the Output page.

SST forcing inputs¶

With native sst_update=1, supply the per-domain wrflowinp auxiliary files and valid NetCDF interval records. Ice-free support requires io_form_auxinput4=2 and a positive auxiliary interval; SEAICE and skin/lake coupling remain refused.

Native cadence and controls¶

Native runs bind per-domain radt and cudt to integer step cadence; requested topo_shading, slope_rad, moist_adv_opt and scalar_adv_opt reach the corresponding controls, in single-domain and nested runs. slope_rad=1 and topo_shading=1 passed a 24-hour comparison with CPU-WRF together with sst_update=1; for the advection options see the namelist page.