wrf_gpu
User's Guide › Performance & validation › Boundaries & Known Issues

Boundaries and known issues

What wrf_gpu v0.4.0 does not cover yet, in plain words. The full technical record is in the repository's known issues and the support matrix.

What the validation covers

  • wrf_gpu is compared with the original CPU-WRF run from the same inputs, not with observations. The results are close to WRF, not bit-identical; small differences grow with forecast time, as between two CPU-WRF builds. No better or worse forecast skill than WRF is claimed.
  • Each option and feature marked validated was checked in one configuration: 65 configurations over 24 hours and Goddard radiation over six hours, mostly in single-domain forecasts. The default physics are the most tested. Experimental, CPU-only and Python-API-only options are outside these checks, and other combinations are not validated.
  • Fixed acceptance limits exist for the main fields (for example 2 m temperature, surface pressure, winds and accumulated rain). The other output fields are compared and reported, but have no limit.

Experimental and partly validated

  • Goddard radiation (ra_lw/ra_sw_physics=5) is validated over six hours, not 24.
  • Ferrier-Aligo microphysics (mp_physics=15) runs but has no reference: the original WRF crashes on the test case.
  • Experimental features: stochastic physics, online diagnostics, station time series, regional output streams, LCZ urban land use, the 3-D TKE turbulence options, most non-default Noah-MP options and Zhang-McFarlane cumulus. See the namelist page.
  • Region set-up (gpuwrf quickstart) is tested on three areas, but GPU forecasts for new regions have not been compared with CPU-WRF.
  • Several GPUs: tested on simulated devices only; real multi-GPU speed is not measured.
  • FLG and GFDL radiation run on the CPU only.
  • Many validated schemes compile to GPU code that exceeds our code-quality limits for speed and robustness (marked 1 on the physics page). They run correctly, but their speed is not measured and may be lower than with the default physics.

Nests and inputs

  • Options outside the default physics are not validated inside nested domains. RUC land, the single-layer urban model, the 3-D TKE options and digital filter initialization are refused in nested runs. Moving nests are not supported.
  • Crop, irrigation, tile drainage and groundwater options need real geography from WPS; a missing field is refused, never filled with zeros.
  • WRF-Chem, WRF-Fire, WRF-Hydro, wave coupling, data assimilation and adaptive time stepping are not part of wrf_gpu. The full list is on the namelist page.

Known numerical issues

  • Some schemes briefly produce tiny negative amounts of water or particle numbers inside a time step, before the same clean-up WRF applies. These events are counted and reported, not hidden; the output contains no NaN or infinite values.
  • The original WRF MYNN scheme reads one variable before setting it on a cold start (an upstream WRF bug). Where it matters, the comparisons use a WRF build in which this variable starts at zero; see the upstream WRF note.
  • P3, Jensen-ISHMAEL, WDM5 and NTU microphysics show small known differences from WRF's own arithmetic (rounding, diagnostics, small undershoots); their forecasts still pass the limits. The known issues describe each one.
  • Free-running open boundaries on wide domains (about 160 columns or more) can become unstable after roughly 14 hours; the normal boundary relaxation avoids this.

Performance and hardware

  • The speed and energy figures were measured with v0.3.2 on one RTX 5090. v0.4.0 has no new whole-forecast benchmark.
  • Only the RTX 5090 is tested. An NVIDIA Ampere or newer GPU is required; older cards (Pascal, Turing) are not supported.
  • The first run of a new grid or physics selection compiles the model, which takes minutes and more host memory than the forecast itself.

Release files

Large microphysics lookup tables, including the Thompson tables of the default physics, are downloaded on first use from the GitHub release. The upload of the v0.4.0 tables is still pending; until it is done, runs that need them stop with an "asset unavailable" message. See runtime tables.

Earlier releases

The validation page keeps the 72-hour comparisons of v0.3.3, including the fields that went over their limits late in those forecasts.