The SWAT+ engine SWATGenX runs — and how far it is from stock | SWATGenX

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, 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 → previous → current-production ladder, 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

Three engines are compared, each pinned. Baseline is stock swat-model/swatplus@5ccf6f0. The current production build that serves SWATGenX is rafiei-vahid/swatplus@247e95b — stock plus a NetCDF backend, the channel_sd print-filter, and the two engine fixes. The middle rung, rafiei-vahid/swatplus@768f1d1, is the previous production (NetCDF + filter, no fixes); it is kept on the ladder to separate the output-size axis from the runtime axis.

All three were run on the same basin and window (Peace River HUC-8 (03100101) — 94,303 HRUs, 90 simulated days, ifx -O3 -ipo). Each is run in its own native output mode — stock writes formatted-text channel_sd for all channels; both fork builds write gauge-filtered NetCDF — so the ladder reflects how each engine would actually be used, not an artificial common setting.

• Baseline: swat-model/swatplus@5ccf6f0 (stock).
• Previous production: rafiei-vahid/swatplus@768f1d1 (NetCDF + filter).
• Current production (deployed 2026-06-06): rafiei-vahid/swatplus@247e95b.
• Each measured number on this page is sourced from the release manifest, not hand-edited.

Stock → previous → current production

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

Figure 1. Wall time and output size across the three pinned engines on Peace River HUC-8 (03100101) — 94,303 HRUs (90 simulated days). NetCDF + filtering crushed size; the two fixes crushed runtime; both are in the deployed build.

Table 1. Stock → previous → current production, each pinned to a commit, with wall time, output size, and ratios versus stock.

The two contribution families move different axes. NetCDF + print-filtering (stock → previous production) 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 (previous → current production) then attack the compute: the same run drops to 227 s, ~2.0× faster than stock with byte-identical results. The deployed engine is therefore ~2.0× faster and ~341× smaller than the stock distribution.

Contributions and their state

Table 2. Every engine contribution: the axis it moves, its headline effect, its state (all in production, each with an open upstream PR), and a link to its deep-dive evidence.

• Production is a pinned commit (rafiei-vahid/swatplus@247e95b) — stock SWAT+ plus a NetCDF backend, print-filtering, and two engine fixes — not a moving label.
• Versus stock on a 94k-HRU basin, the deployed build writes ~341× smaller output and runs ~2.0× faster, with byte-identical results.
• Output size and runtime are independent axes: NetCDF + filtering won on size, the two fixes won on speed, and both are now in the shipped engine. Each contribution is tracked here with its commit, its state (in production; PR open upstream), and a link to its evidence.