SWAT+ runtime benchmark on real watershed models | SWATGenX

The question

Calibration is where SWAT+ runtime actually bites. To fit a model to a gauge, SWATGenX runs it hundreds to thousands of times — one full forward simulation per particle, per iteration of the optimizer — so the wall time of a single run, and the disk I/O it spends writing output, decide whether basin-scale calibration takes an afternoon or a week. The question this page answers is concrete: what actually governs a SWAT+ run’s wall time, and what should you compile and print to make calibration tractable without changing the science.

We answer it empirically, on three real SWATGenX-built models spanning small, medium, and large calibration workloads, changing one factor at a time: output format (NetCDF vs text), print scope (full export vs a gauge-limited calibration profile), the compiler build, and how runtime scales with HRU count.

A controlled, single-variable benchmark

Every run covers the same calendar year on the same model package; within each tier the inputs stay fixed and exactly one factor changes at a time, so a difference in wall time is attributable to that factor and nothing else. All timings are wall-clock seconds on the same host, and the ifx variants are held to a byte-identical output parity rule so a faster build never means a different answer.

Simulation period

365 simulated days (calendar year 2021)

Production binary

Intel ifx release_o3_ipo, from the production SWAT+ fork rafiei-vahid/swatplus @ commit 768f1d1 (rev 61.0.2.61-351-g768f1d1) — the production binary at the time these benchmarks were run; compiler-matrix rows are the same fork commit built with the listed flags. The current deployed engine (247e95b, the same build plus two output-identical engine fixes — see /swat-plus-engine) runs faster still; these tier timings are conservative upper bounds.

Metrics

Wall-clock seconds, seconds per simulated day, bytes on disk

Parity rule

ifx variants match on channel_sd_day.nc (M tier, 20-day check); one-year runs use identical print settings

Test CPU

AMD EPYC 7282 — 10 vCPU KVM guest (5 cores × 2 threads on a 16-core host)

OS / architecture

Linux x86_64, Ubuntu 22.04 (KVM); 64-bit SWAT+ builds

Compilers

Intel oneAPI ifx 2026.0.0 and GNU Fortran 11.4.0. The -xHost variant targets this CPU (AVX2).

Output storage

Local ext4 on a QEMU virtio disk (~650 GB root volume). Each run writes to a temporary folder on that same filesystem, so the clock includes synchronous disk I/O for whatever print profile is enabled.

Each run covers one calendar year. Within each tier, model inputs stay fixed while one factor changes at a time.

Three real models: small, medium, large

We selected three SWATGenX-built SWAT+ models to represent small, medium, and large calibration workloads. Each row is a completed model package built from the same national data stack used in production: NHDPlus HR, PRISM climate, 250 m landuse/soil, and 30 m DEM. Use the Model ID link to open the public package page and download the ZIP.

Table 1. Benchmark basins by tier, USGS model ID, basin name, HRU count, and channel count. Model ID links open the SWATGenX package page where you can download the ZIP.

Beyond one run: the calibration-level levers

The timed scenarios above measure one SWAT+ forward run at a time. These workflow choices reduce I/O, parallelize the optimizer, and stop when the fit stops improving — savings at the calibration level rather than inside a single benchmark cell.

Reduce I/O during calibration

On our medium-tier benchmark model (09471300, Upper San Pedro (AZ), 11,284 HRUs), the shared PRISM folder holds 400 meteorological grid files totaling about 56 MB. A typical PSO calibration uses 48 particles for 50–75 iterations — 2,400–3,600 forward evaluations. If each evaluation copied those grids into a separate TxtInOut, that would add about 135–203 GB of avoidable disk traffic before simulation output is counted.

SWATGenX points pcp_path, tmp_path, slr_path, hmd_path, and wnd_path in file.cio at a shared directory instead. Index files stay in each particle's TxtInOut; the large grid files are read in place. This is already implemented in production and should be part of any calibration I/O plan. Disable with SWATGENX_DISABLE_PCP_PATH=1.

Coarser landuse and soil grids (optional at model build)

Hydrological delineation — stream network, subbasins, and routing — does not depend on landuse or soil grid resolution. Those layers define HRU land-cover and soil assignments after the watershed is built. Choosing a coarser landuse/soil alignment resamples NLCD and gSSURGO to fewer unique combinations and can reduce HRU count and calibration cost, with some compromise in spatial detail of land cover and soil properties. The benchmark models on this page use 250 m landuse/soil with a 30 m DEM; coarser settings are a build-time tradeoff, not a per-run switch.

Use an optimization algorithm with parallel processing

SWATGenX uses particle swarm optimization (PSO), a population-based swarm intelligence method inspired by how birds or fish move as a group toward food. The optimizer keeps a swarm of particles; each particle holds one candidate parameter set and is evaluated with a full SWAT+ forward run. Each iteration updates every particle through social search rules — tracking its own best score and the best score in the swarm — so the population moves toward better calibrations without exploring every combination in the parameter space. When the calibration problem is well posed, fewer forward runs are needed to converge; that depends on the search method and on model structure, not on PSO alone.

Typical pools contain 24–48 particles. We run as many forward models in parallel as CPU and RAM allow, then batch the rest evenly. Early-stop rules cut total simulation count: calibration ends when the best score stalls for several iterations or when the last ten scores barely change after iteration 25.

Caution. Delineation, inputs, and routing need a solid, robust setup — as we apply in SWATGenX with NHDPlus HR. Initialization of model inputs also matters: agricultural management and urban water use must be represented before calibration starts. In groundwater-dominated regions, SWAT+ alone often performs poorly and may need coupling to a dedicated groundwater model. Once the model is structurally sound, the optimizer adjusts parameters — within what the SWAT+ setup can represent — to improve simulated versus observed agreement.

Background: Calibration methods · How it works

What the numbers mean for your calibration

• Full-export runs are I/O-bound. NetCDF matters most when every daily and monthly output is written (Figures 1–2, Table 2).
• Calibration runs are dominated by print scope once output is limited to gauge streamflow (Figures 3–4, Table 3).
• With a filtered calibration profile, NetCDF and text are both workable; choose the format your post-processing tools already support (Table 3).
• Compiler gains on our EPYC host may not transfer to other CPUs, compiler versions, or filesystems (Table 4, Figures 5–7).
• Shared climate paths, parallel PSO with early stop, and coarser landuse/soil grids where acceptable reduce calibration overhead beyond what a single forward-run benchmark captures.

What to ship, and what to print

The fastest path through calibration is to narrow what you print before you tune anything else, write it in a format your post-processing already reads, and run a portable, well-optimized binary.

Runtime is governed first by print scope, not output format: once a calibration run is limited to the gauge channels you actually fit, NetCDF and text are both workable and the format becomes a second-order choice. Format matters where it should — full daily-and-monthly export is I/O-bound, and there NetCDF is the practical default. The compiler is the last lever: Intel ifx beat every gfortran build that ran, and we ship the portable ifx -O3 -ipo — within about 2% of the CPU-pinned -xHost, but able to run on any deployment CPU. And cutting HRUs is not the free speedup it looks like: once routing and model-graph overhead dominate, fewer HRUs do not buy proportional time. Every ranking here is specific to our CPU, compilers, and filesystem — the method transfers, the exact numbers may not, so repeat the matrix on your own hardware before fixing a binary.

• For calibration, print only the stream outputs you fit.
• Use NetCDF for full daily and monthly export workloads.
• For filtered calibration runs, NetCDF and text are both acceptable.
• On Intel hosts like ours, build production binaries with ifx -O3 -ipo — portable across deployment CPUs and within ~2% of the CPU-pinned -xHost — and verify on your own hardware.
• Share climate files across PSO particles and stop calibration when the fit no longer improves.

Biggest runtime lever

Print scope

Full-export format

NetCDF

Production binary

ifx -O3 -ipo

Portability cost vs fastest

~2%

This page quantifies the cost of running a SWATGenX model. How the model is built — and why that build is accurate and reproducible — is covered on the NHDPlus HR vs TauDEM delineation, drainage-area audit, and USGS station-assignment pages.