SWAT+ performance research
SWAT+ runtime benchmark on real watershed models
Measured one-year runtime, output I/O, HRU scaling, and calibration-time estimates across six real basins — with the exact settings SWATGenX uses in production calibration.
Filtered daily channel_sd, production Intel ifx -O3 -ipo, measured on our server. Companion to the SWATGenX engine-acceleration study (manuscript in preparation, 2026).
- 473 → 94k HRUs, six basins
- NetCDF ~4.8× smaller than text
- Print filter cuts tier-M run 269s → 100s
- Portable ifx -O3 -ipo, within ~2% of -xHost
Calibration runtime and output size are two practical limits in SWAT+ modeling. This page is a benchmark study on six real watershed SWAT+ model packages — from 473 to 94,303 HRUs — with measured one-year runs to show where simulation time is spent, which optimizations matter, and how long full calibrations may take on typical servers.
The benchmark keeps basin inputs fixed and changes one factor at a time: full NetCDF versus formatted-text export, filtered calibration output, compiler build, and HRU-count scaling. The figures and tables report timings from our production server. The closing section extrapolates seven-year calibration wall-time ranges from measured init and daily-loop costs.
One scope note up front: every timing here is for a single-core (serial) SWAT+ run, and the seven-year calibration estimates extrapolate that serial per-run cost across the swarm. A single forward run shrinks further on the multi-core SWATGenX engine — the HRU land phase and the channel-routing wavefront are both byte-identical across threads — measured separately on the SWAT+ parallel-engine page. Read the numbers below as the serial-engine reference these accelerations build on.
Fork contributions
- print_filter.prt —
- NetCDF (cdfout=y) —
rafiei-vahid/swatplus (feature/netcdf-cdfout) · swat-model/swatplus
FAQ
Why is my SWAT+ simulation so slow?
Runtime is often dominated by how much output you write and how you store it. Full daily and monthly exports can be I/O-bound; limiting calibration output to gauge streamflow, using NetCDF for large exports, and choosing an optimized compiler build usually matter more than small parameter tweaks.
How can I speed up SWAT+ calibration?
Reduce printed output first, then pick NetCDF or text for your toolchain, then tune compiler flags on your CPU. SWATGenX also shares climate grids across PSO particles, runs forward models in parallel, and stops calibration when the fit stops improving.
What does the SWATGenX SWAT+ runtime benchmark measure?
One calendar year of filtered calibration-style simulation on six real watershed SWAT+ models (473 to 94,303 HRUs). Scenarios change one factor at a time: full NetCDF vs text export, calibration print scope, compiler build, HRU-count scaling, and VTune CPU profiles, while basin inputs stay fixed. The page also estimates seven-year calibration wall-time ranges from measured init and daily-loop costs.
How long does SWAT+ calibration take on a large watershed?
It depends on HRU count, channel routing density, simulation window length, particle count (often 24-48), iteration count (often 30-75 before early stop), and available CPU cores. On our benchmark page, a 94k-HRU Peace River model on a 16-core server is estimated at roughly six days to three weeks for a full seven-year calibration search; smaller basins finish much faster.
How do I reduce SWAT+ output size for calibration?
Write daily channel_sd only at the gauges you calibrate against, with a narrow print.prt and swift_out=0 in codes.bsn. That cuts I/O far more than switching between NetCDF and text on the same print profile.
When should I use NetCDF instead of formatted TXT in SWAT+?
When you need full daily and monthly HRU and stream output for mapping or archives. In our benchmark, text export was several times larger and slower than NetCDF at the same full-export print scope.
How does SWATGenX avoid copying climate files during calibration?
We patch file.cio so pcp_path, tmp_path, slr_path, hmd_path, and wnd_path point at one shared meteorological grid folder. Each PSO particle reads from there instead of copying grid files into its TxtInOut.
How does parallel SWAT+ calibration work?
PSO runs 24–48 particles per iteration, as many in parallel as CPU and RAM allow. The run stops when scores stop improving for several iterations in a row, or when the best fit flatlines after iteration 25.
Next steps
Last updated 2026-07-13.