SWATGenXSWATGenX
Watershed ExplorerPricing
ServicesWatershed ExplorerExample modelsCloud calibrationDocsPricing

SWAT+ production engine

The SWAT+ engine we run in production

SWATGenX runs a pinned release of our fork, currently ship-v1.0-51.3-61-g3a07e3b: a SWAT+ build (NetCDF backend, print-filtering, and two engine fixes) unified with opt-in multi-core, PFAS, and MODFLOW 6.

Pinned per release: ship-v1.0-51.3-61-g3a07e3b (deployed 2026-10-16; commit 3a07e3b for auditors). Ladder measured on Peace River HUC-8, 94,303 HRUs, across the stock and fork builds it names.

Stock → production wall time94k HRUs · 90 days
0125250375500wall (s)462sStock5ccf6f0414sNetCDF+filter768f1d1227sTwo fixes247e95b2.0× faster core341×smaller output695 MB → 2.0 MBMeasured: unified6520940≤ 1e-5 certifiedon plain models+ opt-in multi-core,PFAS, MODFLOW 6
Identical results from stock through the 247e95b rung (the same values; text and NetCDF output cannot be byte-compared). The unified rung (fork@6520940) is certified output-equivalent to it within 1e-5 (worst relative) on plain models; production tracks it forward under the ship gate. Multi-core scaling is on the parallel-engine page.
  • Current pin: ship-v1.0-51.3-61-g3a07e3b
  • 341× smaller output vs stock
  • ~2× faster engine core vs stock
  • Ship-gate certified ≤ 1e-5 on plain models

The release gate that applies this threshold, and the checks every model build runs, are described in how we check models.

The engine also computes each channel's daily water temperature: how it does it, and what it does not yet do.

A recurring question is which exact SWAT+ binary builds SWATGenX models, and how it differs from the stock distribution. SWATGenX runs a pinned release of our fork, and every speed/size claim on this page is measured against the stock original.

It is an overview, not a re-derivation. The detailed evidence for each contribution lives on its own deep-dive page; here we show the cumulative stock-to-production ladder and a changelog of every contribution and its state — of the four output/performance pull requests upstream merged #220 and closed #213, #214 and #219 without merging, and the multi-core, PFAS, and MODFLOW 6 layers live on the open fork.

The current production build is ship-v1.0-51.3-61-g3a07e3b (deployed 2026-10-16; commit 3a07e3b for auditors): the measured fast engine core plus three opt-in capabilities — shared-memory OpenMP parallelism, PFAS fate-and-transport, and a daily two-way MODFLOW 6 coupling (research work). All three are inert at the plain-model serial default. The original unified build (6520940) passed the pre-production ship gate, output-equivalent to the previous engine on ordinary models, before it deployed on 2026-08-01.

FAQ

Which SWAT+ engine does SWATGenX actually run in production?

SWATGenX runs a pinned release of our fork, currently ship-v1.0-51.3-61-g3a07e3b (commit rafiei-vahid/swatplus@3a07e3b, deployed 2026-10-16). On the v1.0-49 build (rafiei-vahid/swatplus@98f7d3bd, 2026-08-05), parallel runs matched the serial engine's NetCDF output in a five-basin matrix at 1-16 threads with routing serial and in a ship gate of 108 checks covering both parallel modes at 2-8 threads; those comparisons read NetCDF only. In October 2026, comparing every output file of the current engine, routing serial matched a one-thread run byte for byte (seven models, one simulated year each), while in the full routing wavefront the channel pesticide output and the PFAS channel mass-balance diagnostic differed between runs; a fix is in progress. The runs we do for customers use one thread per model with routing serial: every run on our server (model builds, extended and climate-scenario runs, SWAT+ Check), and on AWS every PSO calibration run and every climate-ensemble run, many at once, one core each. The one exception is an extended run on AWS, which gives its model the cores the customer picks (2, 4 or 8) for the HRU land phase, with routing still serial. The unified engine's core is rafiei-vahid/swatplus@247e95b (built on the stock swat-model/swatplus baseline plus a NetCDF output backend, channel_sd print-filtering, and two engine fixes, PRs #219/#220), consolidated with three opt-in capabilities: OpenMP parallelism (multi-core HRU land phase + wavefront routing), PFAS fate-and-transport, and a daily two-way MODFLOW 6 coupling (research work). Production is pinned per release, not a moving label — and at the plain-model serial default the parallel/PFAS/MF6 code is inert, so an ordinary SWAT+ build runs exactly as the 247e95b core did.

How does production compare to stock SWAT+?

On a 3-month Peace River run (94,303 HRUs), stock writes a 695 MB channel_sd text file in 462 s; the measured engine core writes a 2.0 MB filtered NetCDF file in 227 s — output size ~341× smaller and wall time ~2.0× faster, with byte-identical results. The unified build 6520940 was ship-gate certified output-equivalent to that core on plain models (worst-relative ≤ 1e-5), so it carried the same numbers at its serial default; its opt-in multi-core scaling (6.91× end to end on the c8a reference node) is measured on the parallel-engine page.

How do you know the unified engine is safe for ordinary models?

Every engine binary passes a pre-production ship gate before it can replace the deployed one. Tier 1 regresses the candidate against the live production engine on plain benchmark models — flow and nutrient worst-relative differences must be ≤ 1e-5 (compiler-noise band) — and separately requires every parallel run to be byte-identical to a serial run of the same binary: exact equality across every variable of every NetCDF output file, at 2, 4 and 8 threads, in both parallel modes, repeated three times per check because a data race is probabilistic and one clean run is not evidence. It does not compare the text outputs, which is how two channel outputs that differ between full-wavefront runs, pesticide and the PFAS mass balance, went unseen until October 2026. Tier 2 validates the coupling and PFAS transport against a committed golden on the Rogue SWAT+/MODFLOW 6 model, with MODFLOW mass-balance discrepancy < 1%. Tier 3 handles deploy safety: it refuses to swap while any model build or calibration is in flight, backs up the previous binary, smoke-tests, and auto-rolls-back on failure. The current 6520940 engine passed all three: 75 checks, zero failures, on 2026-08-01.

Are the engine contributions upstream in official SWAT+?

The four output/performance contributions went to swat-model/swatplus as independent pull requests — NetCDF backend (#213), channel_sd print-filter (#214), hru_read O(1) name lookup (#219), and varinit per-row reset (#220). Upstream merged #220 on 2026-08-20 and closed #213, #214 and #219 without merging, so SWATGenX runs them from the pinned fork today. The parallelism, PFAS, and MODFLOW 6 layers live on the open fork’s main branch (github.com/rafiei-vahid/swatplus) and are documented on their own pages.

Where do the detailed numbers live?

Each contribution has its own deep-dive page that owns its evidence: the performance-profiling page for the two engine fixes, the runtime-benchmark page for output format and print scope, and the parallel-engine page for the multi-core scaling. This page is the changelog/overview that links to them.

Next steps

Build a model of your watershed
SWAT+ parallel engine (multi-core OpenMP)
Hydrology calibration methods

Last updated 2026-07-13.