The SWAT+ engine we run in production

Key takeaways

• The production engine is pinned per release — currently rafiei-vahid/swatplus@6a4b7f1, the unified engine deployed 2026-06-28.
• NetCDF output + the channel_sd print-filter cut output size 341× (695 MB → 2.0 MB) versus stock.
• The two engine fixes then attack compute: the measured engine core runs ~2.0× faster than stock, with byte-identical results — and the unified build is ship-gate certified output-equivalent to that core on plain models (≤ 1e-5).
• The unified engine adds opt-in OpenMP parallelism, PFAS transport, and a MODFLOW 6 coupling — all inert at the plain-model serial default, all deployed today.

What SWATGenX runs, and how far it is from stock SWAT+

"Production" should never be a vague word. The SWAT+ engine SWATGenX builds models with is a specific fork commit — pinned per release — and it differs from the stock distribution in ways we can point to and measure. This page pins down exactly what we run and how far it is from the original.

It is the changelog and the integrator: a stock → fork-production ladder ending at the current unified engine, plus a table of every contribution and its state. The detailed proof for each lives on its own deep-dive page — here we show the cumulative effect, anchored to commits.

Every engine, pinned to a commit

Four engines are pinned. Baseline is stock swat-model/swatplus@5ccf6f0. Two fork rungs were each production in turn: 768f1d1 (NetCDF backend + channel_sd print-filter) and 247e95b (the same plus the two engine fixes). The current production build is rafiei-vahid/swatplus@6a4b7f1 — the unified engine, deployed 2026-06-28: the 247e95b core consolidated with opt-in OpenMP parallelism (HRU land phase + routing wavefront), PFAS fate-and-transport, and a daily two-way MODFLOW 6 coupling. At its serial default all of that is inert, so a plain model runs exactly as before.

The three measured rungs were run on the same basin and window (Peace River HUC-8 (03100101) — 94,303 HRUs, 90 simulated days, ifx -O3 -ipo), each in its own native output mode — stock writes formatted-text channel_sd for all channels; the fork builds write gauge-filtered NetCDF — so the ladder reflects how each engine would actually be used, not an artificial common setting. The unified rung is deliberately not re-timed here: instead of a new benchmark, it carries a certification.

Before the 6a4b7f1 swap, the candidate binary passed the pre-production ship gate (scripts/ship_gate): Tier 1 regression against the then-live 247e95b production engine on plain benchmark models with flow/nutrient worst-relative differences ≤ 1e-5 (the compiler-noise band); Tier 2 coupling + PFAS validation against a committed golden on the Rogue SWAT+/MODFLOW 6 model, with MODFLOW mass-balance discrepancy < 1%; and Tier 3 deploy-time safety (no in-flight builds, timestamped backup of the previous binary, smoke test, auto-rollback). The new physics is inert unless a model configures it, so ordinary SWAT+ builds are unaffected.

• Baseline: swat-model/swatplus@5ccf6f0 (stock).
• Fork productions, in order: 768f1d1 (NetCDF + filter) → 247e95b (+ two engine fixes).
• Current production (deployed 2026-06-28): rafiei-vahid/swatplus@6a4b7f1 — unified engine, serial default, opt-in parallelism/PFAS/MF6.
• Each measured number on this page is sourced from the release manifest, not hand-edited.

Stock → fork productions → current unified engine

Peace River HUC-8 (03100101) — 94,303 HRUs · 90 simulated days.

Figure 1. Wall time and output size across the three measured rungs on Peace River HUC-8 (03100101) — 94,303 HRUs (90 simulated days). NetCDF + filtering crushed size; the two fixes crushed runtime. The current unified engine (6a4b7f1) is certified output-equivalent to the fastest measured rung on plain models, so it inherits these numbers at its serial default.

Table 1. Stock → fork productions → current unified engine, each pinned to a commit, with wall time, output size, and ratios versus stock for the measured rungs.

Unified engine (6a4b7f1): Not re-timed on this ladder. Ship-gate certified output-equivalent (worst-relative ≤ 1e-5) to the 247e95b rung on plain models at the serial default; its opt-in multi-core scaling is measured separately on the parallel-engine page.

The contribution families move different axes. NetCDF + print-filtering (stock → 768f1d1) cut output ~341× (695 MB → 2.0 MB) while wall time changed only ~1.1× — because once output is small, the bottleneck is compute, not I/O. The two engine fixes (768f1d1 → 247e95b) then attack the compute: the same run drops to 227 s, ~2.0× faster than stock with byte-identical results. The unified engine (6a4b7f1) keeps that measured core — certified output-equivalent on plain models (≤ 1e-5) — and adds the opt-in capabilities: multi-core scaling (measured on the parallel-engine page), PFAS transport, and the MODFLOW 6 coupling.

Contributions and their state

Table 2. Every engine contribution: the axis it moves, its headline effect, its state (output/perf contributions have open upstream PRs; the parallel/PFAS/MF6 layers live on the open fork), and a link to its deep-dive evidence.

• Production is pinned per release — currently rafiei-vahid/swatplus@6a4b7f1 (deployed 2026-06-28), the unified engine: the measured 247e95b core plus opt-in OpenMP parallelism, PFAS fate-and-transport, and a MODFLOW 6 coupling, all inert at the plain-model default.
• Versus stock on a 94k-HRU basin, the measured engine core writes ~341× smaller output and runs ~2.0× faster, with byte-identical results; the unified build is ship-gate certified output-equivalent (≤ 1e-5) to that core on plain models.
• Output size and runtime are independent axes: NetCDF + filtering won on size, the two fixes won on speed, and both are in the shipped engine. The four output/perf contributions each have an open upstream PR against swat-model/swatplus (#213/#214/#219/#220); the parallelism, PFAS, and MODFLOW 6 layers live on the open fork's main branch and are documented on their own pages.