Turn global spatial data into watershed intelligence.
SwaNET does the heaviest lifting in watershed modeling: DEM, land use, soils, climate, stream networks, HRUs, simulation, visualization, and monitoring data are brought together so users can focus on insight.
Draw a box on the global map. Generate a working watershed model in minutes from the global base database. When the base needs refinement, use DataNET to evaluate and transfer additional DEM, land use, soils, climate, hydrography, telemetry, or local management data — then see which processes matter, how they connect, and how they change under assumptions, BMPs, land use, and climate scenarios.
See SwaNET turn spatial data into watershed system understanding.
After the platform logic is clear, the flipbook shows the working experience: draw a basin, build the watershed model, visualize terrain, land use, soils, climate, HRUs, calibration, water balance, process connectivity, Sankey logic, BMPs, land-use scenarios, and climate response.
Draw a box. Get a complete watershed model. Steer.
SwaNET is a computational steering system for watersheds. You draw a box on the global map; typically in under 10 minutes under default settings (the exact time depends on simulation duration and watershed size), the platform generates a complete working watershed model with full simulation results across the entire simulation time span — streams and watersheds delineated, HRUs built, the surface system, vadose zone, shallow aquifer, deep aquifer, stream routing, reservoirs and ponds all coupled and solved, with hydrographs, water balance, Sankey, 3D watershed visualization, and recharge fields ready to inspect. Traditional end-to-end watershed modeling from scratch is a labor-intensive process that takes months — often much longer. SwaNET eliminates the human time entirely; machines do the heavy lifting in the background while the user stays free to think about modeling decisions. Setup becomes the platform's job; modeling becomes the user's.
Computational steering is an established concept in scientific computing: the human directly controlling a running computation, observing and steering it as it evolves rather than waiting for batch results. SwaNET is the system built end-to-end around this principle, adapted to watershed modeling — where the "loop" closes between iterations rather than at the time-step level. The user steers across five dimensions: the iteration loop itself (each rerun closes the loop with the new state of the watershed model visible), scenarios (BMPs, land-use change, climate projections), the conceptual model (subbasins, HRUs, ponds, reservoirs, management practices), the numerical model (infiltration method, routing scheme, ET method, erosion approach), and the visualization itself — Sankey, hydrographs, water balance, sediment and nutrient breakthrough charts, maps, and the 3D watershed substrate where users rotate, tilt, and interactively fuse input and output overlays in spatially explicit form.
The model runs from minute 10 because the platform engineers intelligent defaults that favor robustness — convergent, sensible starting conditions for infiltration, routing, ET, erosion, and the coupled subsystems, so the user gets a working watershed model immediately rather than a failed run with no signal. Every default is fully editable; the user refines for accuracy where it matters. Conventional watershed workflows are pipelines of disconnected tools wrapped around the SWAT engine. A computational steering system is different in kind — the user is inside the iteration loop, not orchestrating it from outside.
Standing on the work of generations. Built for the scale that work created.
The watershed data foundation already exists. USDA built and refined SWAT over decades — with the canonical model documentation and reference datasets maintained at Texas A&M University, which HydroSimulatics' preprocessed database draws on.
NRCS built the SSURGO and STATSGO2 soils infrastructure for the US; FAO delivers the global Soil ID Map at 300m with 90m subsets for global watershed work. NOAA built PRISM climate fields and CFSR reanalysis; the NCEI Access API will bring live-linked rain-gauge point time series (~70K GHCN-Daily + ~5,500 HPD hourly stations) next release, with PRISM 800m bringing finer-resolution US climate. USGS built the streamflow monitoring network across the country, and Canadian agencies built the equivalent in their territory — both live-linked via direct sensor API (parallel architectures). NHDPlus high-resolution streams (USA) and HydroSHEDS global hydrography (HydroBASINS, HydroRIVERS, HydroLAKES) sit in the SwaNET pre-integrated base for visualization, validation, and optional overlay — though SwaNET delineates its own watersheds and stream networks directly from the DEM, so no pre-existing hydrography dataset is required for model setup. USGS 3DEP brings continental-scale multi-resolution LiDAR; SRTM 30m and ASTER 1000/300/90m provide global terrain today, with GEDTM30 30m bare-earth DTM coming next release. SwaNET does not use IDF data — SWAT does not handle event-based storms.
The numerical methods matured — SWAT, MUSLE, kinematic routing, vadose-zone parameterizations, HRU representation, multi-station calibration — all rigorously validated, open-source, in the hands of every watershed modeler.
Preprocessed once. Multi-resolution by construction.
Watershed-scale modeling typically operates at DEM resolutions from 30m to 1km. The right starting point is 90m or coarser — sufficient for most watershed and river-basin applications because subwatershed boundaries follow topographic divides, which are robust to DEM resolution. Finer DEM doesn't improve flux accuracy in SwaNET (fluxes between subwatersheds are exactly zero by construction). Finer only adds value when subwatershed delineation itself needs more detail.
Draw a box on the global map at any of these scales and SwaNET starts from context, not from a blank page.
Do it once, for all
The preprocessing happens once at the global level — at every resolution practitioners use. No individual project re-ingests SSURGO, re-classifies global land cover, or rebuilds the DEM stack. The architecture frees every project from the work that should never have to be repeated.
DataNET extends, not replaces
The global preprocessed base covers the typical watershed workflow. DataNET is the enrichment layer: when local-area data improves on global products — finer land-use surveys, regional climate downscalings, project-specific monitoring — it federates the better data in, dynamically, without disturbing the base.
Where the bottleneck moves
Watersheds are inherently scenario-heavy: BMP placements × climate scenarios × land-use scenarios × calibration variants. In conventional workflows, weeks of setup precede every scenario evaluation — so practitioners do fewer scenarios than the science calls for. SwaNET makes the initial setup essentially free; the entire workflow becomes scenario-dominant. The bottleneck moves from data assembly to the question that actually matters.
Three foundational layers, then incremental modeling.
Conventional watershed workflows are linear pipelines: process DEM, classify land use, join soils, ingest climate, build HRUs, configure SWAT, run, export, then visualize in another tool — each step its own tool with its own format, every handoff creating I/O, delay, and inconsistency. SwaNET keeps them all in one platform: three foundational layers ready before any work begins, then an incremental workflow where each placement grows what's already a working model. You don't orchestrate between steps. You steer between iterations.
The steering system rests on three foundational layers.
At basin scale, the dominant information comes from top-down spatial data — a Great Lakes basin, an Amazon basin, or a national-scale watershed cannot be built from manual collection alone. Terrain shapes drainage; land use modifies runoff; soils control infiltration; climate forces the response. The data is causally upstream of every answer the model gives.
SwaNET pre-integrates all of these — multi-resolution where possible, instantly extracted for any box you draw:
Spatial fabric
Terrain, land cover, soils — the geometry the watershed model rests on. SwaNET delineates streams, subwatersheds, and the watershed boundary directly from the DEM (no pre-existing hydrography required). Cover and soil classes map into model parameters via lookup tables.
Stress framework
The forcing the watershed responds to — continuous climate, future scenarios, management practices. SwaNET is the platform's pathway for climate-change studies. SwaNET does not use IDF data — SWAT operates on continuous time, not event-based storms.
Calibration data
The evidence the watershed model is tested against. When the user wants to calibrate, a single click pulls the gages within the model area, formats the time series, and loads them for comparison — manual where judgment matters, automated multi-station where the search is well-posed.
The foundation evolves — refreshed as agencies update, extended through DataNET, deepened with each release.
Plus the engineered defaults that make the model run.
The platform sets default infiltration scheme (SCS Curve Number), default channel routing (Variable Storage), default ET method (Penman-Monteith), default erosion scheme (MUSLE), default groundwater partition between shallow and deep aquifer, default soil profile parameters, and default management assumptions. Where engineering trade-offs exist between numerical robustness and parameter accuracy, the platform chooses robustness — robustness for the first run; accuracy for the user's refinement.
Five things happen at once.
Generate
Draw a box on the global map. SwaNET uses the DEM to delineate the stream network, subwatersheds, and overall watershed boundary — no pre-existing hydrography dataset required. Outlets identified where streams merge; the outlet with the largest watershed becomes the model boundary. Land use and soils extracted via lookup tables; HRUs built. All with intelligent defaults, ready to simulate.
Simulate
Run the SWAT-based basin model: surface, vadose zone, shallow aquifer, deep aquifer, stream routing, reservoirs and ponds — all coupled, daily time step, full simulation time span computed automatically.
Visualize
See maps, 3D views, streamflow time series, water balances, sediment and nutrient breakthrough, and the Sankey process-connectivity diagram — all in the same platform, with no export to a separate tool.
Calibrate
Click to download USGS or Canadian streamflow gage data for the model area; the platform automatically pulls the right stations, formats the time series, and loads them into the model for comparison. Manual calibration where judgment matters, automated multi-station calibration where the search is well-posed.
Refine
Test BMPs, land-use scenarios, climate projections, calibration alternatives, refined resolution. Each iteration reruns in the same platform; the Sankey reorganizes; the water balance updates; the assumptions that change the answer become visible.
Cross-validated against canonical QSWAT / SWAT Editor.
SwaNET uses the USDA SWAT engine. The key interface question is whether the web workflow correctly converts user choices, geospatial layers, delineation settings, HRU rules, weather inputs, and simulation configuration into standard SWAT input files. A controlled SwaNET–QSWAT comparison confirms that the SwaNET interface/preprocessing layer reproduces the canonical QSWAT / SWAT Editor workflow for the tested case.
Watershed delineation, subbasins, HRUs, basin water balance, outlet flow, sediment, water-quality, reach, and subbasin outputs matched across the two workflows — evidence that SwaNET modernizes the interface while preserving canonical SWAT behavior.
A real watershed model at subbasin resolution.
SwaNET creates the same core structure used by professional SWAT modeling, automatically: subbasins defined by terrain-driven drainage; Hydrologic Response Units (HRUs) formed from land use × soil × slope; multi-layer soil profiles; channel routing; daily water-balance accounting. Outputs are lumped at the subbasin scale — this is the SWAT paradigm and the spatial scale at which watershed questions typically need to be answered.
Subbasins
Topography defines drainage areas and stream-connected subbasins. Watershed boundaries are terrain-derived flow systems.
HRUs
Land use × soil × slope combinations within each subbasin — the SWAT computational unit, generated automatically from the multi-resolution data stack.
Water balance
SwaNET tracks precipitation, evapotranspiration, surface runoff, soil moisture, lateral flow, percolation, recharge, baseflow, stream routing, sediment, and nutrients — daily, across every subbasin.
Three commitments behind every basin-scale model.
Foundations and a workflow are not enough. The answers SwaNET produces at basin scale have to be defensible — computationally, operationally, and empirically. Three architectural commitments do that work: natural cells that stay tractable at any scale, alignment between modeled cells and the manager's decision units, and a live link to national streamflow networks for observation-grounded calibration.
Natural cells. Lumped within. Exact between. Tractable at scale.
SwaNET's architecture is structurally different from most watershed solvers — and the difference shapes what resolution you need, what the platform answers well, what it scales to, and where it couples.
Subwatersheds are natural cells. Fluxes between them are zero. Computation stays tractable.
Every watershed model divides into cells. Accuracy depends on quantifying the flux across cell boundaries — and that flux is exactly what the Saint-Venant equations of conventional grid-based watershed solvers exist to handle. SwaNET solves the flux problem differently: it uses natural cells — subwatersheds delineated from the DEM, subdivided into HRUs by land-use × soil. Cells are coupled through the stream network, not through grid-based overland flux exchange.
The boundaries are drainage divides; water doesn't cross them at the surface — that's what makes them subwatersheds. Overland flux between subwatersheds is exactly zero by construction. SwaNET doesn't approximate the cell-to-cell fluxes; it solves them analytically. Solved by geometry, not by numerics.
And because the flux is solved analytically, there is no Saint-Venant equation to discretize, no CFL stability constraints, no required tiny cells or short time steps. Computation at basin scale stays tractable. Modern high-resolution DEMs are what make this work everywhere — they're how SwaNET can delineate accurate subwatersheds at different scales worldwide. Heterogeneity within each subwatershed is preserved through HRUs.
Grid-based watershed solvers face all three costs at once: approximation error in cell-to-cell fluxes, the computational expense of Saint-Venant PDE solution over many small cells, and the need for data at grid scale that often doesn't exist. SwaNET's architecture is why SWAT became the global standard for watershed-scale modeling. Lumped within cells. Exact between cells. Tractable at scale.
Start coarse. Refine only where it matters.
Refinement works in SwaNET the way it works in any watershed model — higher-resolution DEM, lower stream-delineation threshold, more subwatersheds, more compute. The principle in SwaNET is when. Because the flux between subwatersheds is exact at any resolution, finer DEMs don't improve flux accuracy — they only add detail to where subwatersheds get drawn.
So begin coarse — match resolution to basin size, not to data availability:
- 10–30m for very small or topographically complex watersheds (roughly under a few hundred km²)
- 30–90m for typical small-to-medium watersheds and rural basins (a few hundred to several thousand km²)
- 90–300m for large basins (several thousand to tens of thousands of km²)
- 300m and coarser for very large basins and continental-scale work (Great Lakes, Amazon, Mississippi, Niger)
LiDAR and meter-scale DEMs are rarely needed for watershed-scale work — finer DEM resolution adds detail to subwatershed boundaries without improving flux accuracy.
The initial solution shows you where refinement matters and where it doesn't — which subwatersheds drive the response, where finer detail would change something, where it wouldn't. Refinement becomes another dimension of steering — guided by what the previous run revealed, not by a guess made upfront. Everything has a purpose; nothing is finer than the question requires.
SwaNET handles the watershed. The one direct coupling is to IGW-NET.
SwaNET resolves surface water balance, sediment and nutrient transport, stream-flow routing, scenario combinatorics (BMPs, land-use change, climate projections), and recharge as boundary condition. Reservoirs and ponds are handled in lumped, effective formulations; stream flow uses routing (Muskingum, variable-storage) — not full Saint-Venant. This is appropriate for watershed-scale water balance; not appropriate for individual reservoir operations, backwater, or detailed 1D channel hydraulics, which are outside SwaNET's scope.
For subsurface storage dynamics — aquifer depletion, mining, GRACE-style basin-scale anomalies that SwaNET's lumped shallow-aquifer formulation does not resolve in 3D — SwaNET couples to IGW-NET. The full cross-platform picture is in How watersheds fit in the network below.
Natural cells = computational cells = management cells.
SwaNET's subwatershed cells serve three roles at once. They are natural cells — the way water drains, defined by terrain. They are computational cells — the unit over which water balance is computed. And they are management cells — the spatial unit watershed management actually operates on. Conservation districts plan BMPs by subwatershed. Regulators assess loads (e.g. TMDL allocations) by subwatershed. Water agencies monitor streamflow at subwatershed outlets. Agricultural conservation programs target practices to drainage areas. In conventional grid-based modeling, these three roles almost never coincide — output from rectangular grid cells has to be aggregated to natural drainage areas, then reprojected for management decisions, then mapped back to grid cells when assumptions change. SwaNET removes the translation step. The model's degree of freedom is the manager's decision space; the manager's spatial unit is the modeler's spatial unit; the regulator's unit is the natural unit. The model speaks the language of the people who use it.
National gage networks. One live comparison.
SwaNET is connected to national monitoring networks — USGS and Canadian streamflow gages, water-quality observation programs. When the user wants to calibrate against monitoring time series, they click to download the gage data for the model area; the platform automatically pulls the right stations, formats the time series, and loads them into the model for comparison. Calibration data assembly — one of the most painful tasks in conventional watershed workflows — collapses to a single click. The user then compares, diagnoses, refines, and updates iteratively: manual calibration where judgment matters, automated calibration where the search is well-posed.
Five scales of steering. The Sankey reveals what controls the system.
This section shows what the architecture distinctively enables — steering at five different scales, and a Sankey diagram that becomes a live diagnostic instrument for reading what controls the system. Conventional watershed workflows fragment iteration across tools: change a BMP in one program, re-export to SWAT setup, rerun SWAT in batch, export outputs, re-plot in another tool, manually compare. Each iteration crosses tool boundaries; setup costs pay themselves over and over. SwaNET keeps every iteration inside one platform. Change a BMP, rerun, the Sankey reorganizes. Change land use, rerun, the runoff band thins. Refine DEM, the platform regenerates the fabric and reruns. Each iteration closes inside the same environment, with the same calibration data already loaded, the previous run still visible, the new run ready to compare.
What's shown, how it's read, what drives it, how it's computed, and what's conceptually represented.
The five scales correspond to five dimensions the modeler adjusts: display, 3D twin perspective, parameters, numerical methods, and conceptual fabric. Each kind has a specific rerun cost; together they make "human in the loop" a complete architectural commitment, not a feature.
Display steering
What's shown in charts and time series. Sankey emphasis, hydrograph time range, water balance breakdown, sediment and nutrient charts, parameter visualizations, table-level controls — adjusted in the same platform without rerunning the simulation. Fast — no big-data operations triggered.
3D watershed steering
Spatially explicit understanding. The user rotates, tilts, and inspects the 3D watershed model interactively — DEM surface with adjustable vertical exaggeration, subwatershed boundaries, stream networks, and outlets visible together. Fuse any input or output as a texture on the terrain: land use, soils, climate as inputs; recharge, runoff, ET, erosion, sediment yield, nutrient loads as outputs. Watershed ridges, drainage divides, runoff concentration zones, and recharge patterns reveal themselves through interactive inspection — fast, no big-data operations triggered, just the user's diagnostic attention.
Property steering
Parameter values. Curve numbers, soil hydraulic parameters, ET coefficients, management practice parameters, calibration variables — change them, the platform reruns the simulation against the existing watershed fabric. Fast — no big-data operations triggered, just the simulation rerun.
Numerical steering
Method choices. Switch infiltration scheme (Curve Number ↔ Green-Ampt), routing scheme (Variable Storage ↔ Muskingum), ET method (Penman-Monteith ↔ Hargreaves ↔ Priestley-Taylor), erosion approach. The platform reruns with the new methods against the existing fabric. Fast — no big-data operations triggered, just the simulation rerun.
Conceptual steering
The watershed itself. BMPs, HRU reconfiguration, local land-use patches stay fast — they adjust the model within the existing fabric. Refine land use across the watershed, soils across the watershed, or DEM resolution — and the platform regenerates the affected layer: stream and watershed delineation if DEM changes, land-use re-extraction if land use changes, soil re-extraction if soils change. You pay only for the work your question requires — and even the full DEM-refinement case completes in a fraction of the time traditional setup takes.
The Sankey is watershed intelligence.
One diagram captures the complete process topology of the modeled watershed: what is simulated and what is not, what is important and what is not, what is dominant and what deserves attention, whether the fluxes make sense. The Sankey is where watershed understanding forms — not a final report, but the diagnostic instrument the user reads to build intelligence about the system. Change a BMP, rerun, the recharge band thickens. Change land use, rerun, the runoff band thins. Shift climate, rerun, the whole network reorganizes. How this intelligence changes with steering — that is what reveals the watershed's actual dynamics.
overland · soil · vadose · shallow aquifer · deep aquifer · streams
Process magnitude, connectivity, response, uncertainty, and priorities for refinement — all in one diagram, all at once. It rebalances each time you iterate, in the same platform, and that's how watershed understanding deepens.
Complexity becomes visible
The user sees which processes dominate the water balance, which pathways are minor, and where refinement is likely to matter. Wet forested basin vs dry urbanized basin: the dominant flow paths are completely different. You don't have to predict — the Sankey shows you.
Connectivity revealed
Hydrologic pathways become connected and interpretable: precipitation, runoff, infiltration, recharge, baseflow, streams, storage, sediment, and nutrients. The system isn't a list of equations; it's a structure the user can see.
Scenario response
The user sees how the system reorganizes under BMPs, land-use change, management assumptions, and future climate scenarios — not as a separate analysis run with separate post-processing, but as the Sankey shifting on the next iteration.
Understand the Sankey before you calibrate.
The Sankey reveals overall interrelationships and relative magnitudes — which fluxes dominate, which connections drive the system, whether the simulated water balance makes physical sense. Watershed modeling is fundamentally about water balance, and other dynamics (sediment, nutrients, BMP effects) follow from how water moves. Calibration before understanding is precision without direction — the user adjusts parameters to fit gauge data without knowing whether the underlying system representation is right. SwaNET's recommended workflow inverts this: read the Sankey first, build watershed intelligence, then calibrate strategically against the questions that matter. This is a methodological commitment, not a feature — supported because the Sankey is in the same platform as the simulation, ready to read as soon as the model is built.
You don't refine everything. You refine what matters.
Real-time Sankey requires no disconnect between simulation and visualization. Change parameters, rerun, watch the Sankey shift — without leaving the platform, without re-importing, without re-plotting. Conventional toolchains have a Sankey somewhere (or can produce one), but the visualization lives in a separate tool from the simulation; iteration means export, re-plot, manually compare. The architectural difference is verifiable in practice: how many steps stand between changing a parameter and seeing the system response. SwaNET doesn't just run the model — it reveals the system. The user shifts from blind refinement to targeted learning: identify dominant controls, test assumptions, collect better data, calibrate strategically, and make better watershed decisions.
Machines compute. Humans decide.
Machines are fast at moving massive datasets, processing DEMs, delineating streams, generating HRUs, running SWAT, and connecting to national monitoring networks. People are slow at repetitive setup but powerful at interpretation, strategy, judgment, and decision-making. SwaNET puts machines on machine work, humans on human work — and connects them through the iteration loop. Traditional watershed modeling from scratch is a labor-intensive process; human-in-control of the system understanding has been aspirational rather than practical. SwaNET makes it actually possible. This is not a watershed modeling tool. It is a computational steering system.
Watersheds don't stand alone. Neither does your work.
SwaNET is one of five expressions of the MAGNET4WATER architecture. Its one direct data-exchange coupling is to IGW-NET — boundary, recharge, and projection flowing as fields, aquifer questions resolved properly. DataNET federates additional data context to SwaNET worldwide when the preprocessed multi-resolution database needs local enrichment — alongside the always-on preprocessed database that direct-links SwaNET to essential layers (DEM, base soils, base land use, base climate). StormNET is a sister watershed platform of SwaNET — both watershed modeling platforms sharing the same dimensional architecture (lumped water balance within cells, routing between cells, 2D inundation derived), but with no model-to-model data flow; SwaNET applies at river-basin and rural-watershed scales with multi-layer soil for crop root uptake, StormNET at urban scale with full 1D Saint-Venant. ConduitNET handles pressurized supply networks separately. In future releases, IGW-NET will provide water-table information to both watershed platforms (SwaNET at HRUs; StormNET at subcatchments) for antecedent-state initialization. The family shares architectural principles and the data-enabled landscape. And — when you choose — your work joins the Global Model Network and the Model Observatory, where your published work becomes the foundation for the next person's work.
Boundary, recharge, projection — flowing as fields, not as files.
Watershed recharge is not just an output — it can become a physically meaningful input to IGW-NET, where 3D aquifer response is resolved through groundwater flow and transport modeling. Basin-scale watershed models are ideal for runoff, recharge, sediment, nutrients, and management scenarios; questions about well impacts, capture zones, losing reaches, or aquifer depletion belong in IGW-NET. The handoff between them is a complete package — watershed boundary, recharge field, and projection system (typically UTM) flowing as fields, not as files. The recharge field becomes part of the IGW-NET steering system's stress framework, updating automatically when the upstream watershed scenario changes. Change SwaNET's land use, the recharge field shifts, IGW-NET reflects it. IGW-NET handles region-specific projection systems natively — no manual reprojection, no coordinate-system mismatches between watershed and aquifer boundaries, no silent offsets that flip capture-zone or well-impact answers. The same no-disconnect property that keeps each platform's loop coherent keeps the cross-platform integration architectural, not procedural.
SwaNET computes the package
Daily watershed water balance produces recharge fields; watershed delineation produces the spatial boundary; the model's UTM projection is preserved throughout.
Server exchange transfers fields
Boundary, recharge, and projection transfer as a coherent spatial package, not as manually reconstructed files between disconnected tools. The exchange is architectural, not procedural.
IGW-NET resolves aquifer response
The recharge field becomes a groundwater boundary condition for 3D head, flow, particle, and transport analysis — well impacts, capture zones, depletion, and contaminant movement — in the native projection, no manual reprojection required.
One architecture. Five expressions.
The MAGNET4WATER platforms share architectural principles — natural or domain-appropriate cells, integrated iteration loops, real-time visualization with cost or calibration feedback, no-export workflows — and a common preprocessed data foundation. The homepage Cross-Platform Guide documents the full family — sister watershed platforms, the recharge handoff, the water-table fanout, sister pipe-network platforms, the unsaturated zone across three platforms, and the two complementary data routes (preprocessed multi-resolution database + DataNET federation).
StormNET SISTER PLATFORM
Urban water systems — drainage, sanitary, distribution, harvesting, channels, LIDs. SwaNET and StormNET are sister watershed platforms, with similar overland routing models but no model-to-model data flow. Both are watershed modeling platforms sharing dimensional architecture (lumped water balance within cells; routing between; 2D inundation derived). They differ in routing physics (SwaNET hydrology-based; StormNET 1D Saint-Venant), storage element treatment (lumped effective in SwaNET; explicit per element in StormNET), and subsurface depth (SwaNET multi-layer soil for crop root uptake; StormNET single vadose + one aquifer). Same architecture, complementary scales — pick the platform whose physics and scale match the dominant question.
Explore StormNET →ConduitNET SISTER PLATFORM
Pressurized water supply networks — drinking water distribution, raw-water transmission, irrigation. ConduitNET is a focused pure pipe-network platform using time-dependent (unsteady) analysis via quasi-steady equations — right equations for the pressurized regime (pressurized pipes have negligible storage; time dependence enters through demand patterns and tank dynamics). Different physics regime from SwaNET watershed modeling; no direct relationship to SwaNET. ConduitNET is a sister pipe-network platform of StormNET (pipe-network mathematical superset/subset).
Explore ConduitNET →DataNET FEDERATED ROUTE
Federation hub plus 3D site characterization platform. DataNET federates additional context to SwaNET worldwide — municipal GIS, regional climate downscalings, monitoring stations, project-specific overrides — alongside the always-on preprocessed multi-resolution database that direct-links SwaNET to essential layers (DEM, base soils, base land use, base climate). Two complementary routes by design.
Explore DataNET →Case studies
Great Lakes basin, agricultural watersheds, BMP evaluation, climate impact assessment, regional planning — production deployments where SwaNET turned the paradigm into practice.
View case studies →Your work joins the network.
Your SwaNET work can stay private to you, shared with your team, or published to the Global Model Network. Models published to the Model Observatory become accessible to other watershed practitioners. Data served from your own GeoServer node — visualized in DataNET by URL, transferred directly to any modeling platform — stays on your own infrastructure with access under your control. Your work persists across projects — and across the careers of people whose work it informs. This is how infrastructure grows: every new participant who shares, makes the network slightly richer for everyone else.
Model Observatory
Publish your SwaNET model to the Observatory in under a minute — a feature shared across all five platforms. Your work appears as a pin on a global map, styled by model type.
Click any pin → a local Observatory page opens with:
- Your model graphics and downloadable model file
- An AI-generated report grounded in the model file (data used, assumptions, parameters, findings)
- A live USGS National Water Network overlay — streamflow gauges, hydrographs, water-quality time series, precipitation — as statistics, historical series, and realtime
Private or public — your choice. The USGS overlay appears on every Observatory page regardless of platform.
On the roadmap: auto-generated DataNET fusion, Cesium 3D, lidar.
Browse the Observatory →Publish your data through GeoServer
For organizational data you want across projects and colleagues — high-resolution land use, regional climate downscalings, monitoring observations — stand up your own GeoServer node (or any WMS/WFS/WCS-compliant server).
- Your service does not appear in DataNET's curated hub
- You can point DataNET at your service URL to visualize and analyze your data
- You can transfer your data directly to any modeling platform
- Data stays on your own infrastructure; your server controls access
Recharge trajectory, aquifer dynamics, ecosystem impacts.
SwaNET handles the recharge trajectory under human and climate forcing over decades. IGW-NET handles the aquifer dynamics that result, with system-wide propagation through head-driven fluxes. Together they form the complete sustainability picture; alone, each answers a different question.
What SwaNET delivers: 50 years of recharge under change.
SwaNET simulates the basin's recharge flux as a continuous time series:
- Land-use change via the LUP routine (
lup.dat): annual or decadal HRU composition updates representing forest-to-suburban-to-urban transitions, agricultural expansion or contraction, conservation programs. - Reduced infiltration through impervious area: urban CN auto-adjustment captures the runoff/recharge consequences of development; recharge declines as impervious fraction grows.
- Climate variability and climate change: daily precipitation and temperature drive the soil-water balance; wet/dry interannual variability and decadal climate trends propagate through the recharge calculation.
- Crop water use: auto-irrigation activated by soil-water-deficit threshold (
AUTO_WSTRS) responds to climate variability and to LUP-driven changes in irrigated acreage.
Output: recharge as a time series at each subbasin or HRU, capturing the basin's cumulative human-activity and climate signature in flux form. This is the right product of basin-scale water-balance modeling.
What SwaNET cannot resolve: system propagation through head-driven fluxes.
SWAT tracks per-subbasin aquifer storage (shallow aq_sh and deep aq_dp) with mass balance. But the bucket-to-bucket fluxes are configured rates, not deficit-driven physics:
- Shallow ↔ deep aquifer: percolation is a fixed fraction
RCHRG_DP × w_rchrg,sh(Chapter 2:4.2.2). The flux does not depend on the difference between shallow storage and deep storage. If shallow is mining down, deep cannot compensate. - Shallow aquifer ↔ stream/reach: baseflow uses water-table elevation only as a threshold switch (eq. 2:4.2.9) — full recession-driven baseflow above threshold, zero below. The flux does not depend on the difference between aquifer head and stream stage. Aquifer drawdown does not propagate continuously into stream depletion; losing-reach reversal (when stream stage exceeds aquifer head) is not represented.
- Shallow aquifer ↔ pond/wetland: similar threshold-based behavior; not head-driven.
- Deep aquifer ↔ stream: typically deactivated (water in deep is "lost from system"); when activated, similar recession-style equation, not head-difference-driven.
The systemic consequence: aquifer pumping in one subbasin cannot propagate through SWAT into stream depletion, wetland decline, deep-aquifer compensation, or losing-reach reversal — because the propagation physics (head differences driving flux) is not in the model.
SwaNET also cannot track absolute cumulative-decline trajectories: initial aquifer conditions are arbitrary and flushed by warm-up (no absolute reference frame), and the .wus consumptive-use file specifies 12 monthly daily-average values applied identically every year (no inter-annual variation in municipal/industrial demand). Spatial gradient within a subbasin is also absent — one lumped aq_sh per HRU/subbasin means no cones of depression, no well-by-well failure mapping.
What IGW-NET adds: aquifer dynamics with system propagation.
IGW-NET takes recharge from SwaNET as input and resolves:
- Initial water-table maps and aquifer geometry as inputs — absolute reference frame for cumulative decline.
- Time-varying pumping at points — wells with specified screens and withdrawal time series; growing municipal demand over decades natively supported.
- Continuous heads at (x, y, z) at every time step — the spatial-temporal head field that real sustainability questions require.
- Head-driven fluxes between every storage element — aquifer-to-stream baseflow responds continuously to head difference (gradual capture-curve depletion under increasing pumping; losing-reach reversal during high stream stage); inter-aquifer leakage responds to head difference (shallow ↔ deep when 3D layers are added); wetland and pond connections respond to head difference.
- Cumulative-decline trajectories — water-table elevation tracked against absolute reference; well-by-well failure timing; depressurization fronts; cones of depression.
Coupled SwaNET-IGW-NET resolves ecosystem-scale sustainability.
Where IGW-NET's LiDAR-resolution surface representation meets head-driven flux physics, the coupled model produces ecosystem-scale sustainability outputs:
- Seeps, wetlands, and fens emerge from physics where computed head meets LiDAR-resolved surface elevation — no hand-mapping required.
- Wetland evolution over time — under coupled climate change, land-use change, and growing pumping, the model resolves how wetlands shrink as water tables drop, fragment when head fields fall below some pixels but not others, and disappear where heads drop persistently below their bottom elevation.
- Continuous stream baseflow depletion under growing pumping — the gradual capture-curve signature (Theis 1940, Barlow & Leake 2012), with losing-reach reversal during high stream-stage periods.
- Fen-scale feature responses — small, head-dependent ecological systems whose persistence depends on continuous groundwater discharge; LiDAR resolution and head-based physics together let the model track these features individually.
- Cones of depression and well-by-well failure timing — spatial signature of cumulative pumping; where wells fail first; how depressurization fronts propagate across the basin.
- Ecosystem and habitat consequences — cold-water fish habitat under reduced baseflow; riparian vegetation under falling water tables; migratory bird stopover wetlands under fragmentation.
These are the visible, ecologically-meaningful sustainability outcomes that policy-makers, planners, and ecologists need. SwaNET alone cannot produce them; IGW-NET alone (without recharge trajectory) cannot drive them; the coupled system resolves them. This is the architecturally complete sustainability picture.
How IGW-NET resolves aquifer dynamics — algorithm, boundary taxonomy, streaming diagnostics.
The aquifer side of the SwaNET → IGW-NET handoff is itself a substantive piece of architecture. The 3D unconfined-aquifer free-surface problem — classically tough because the water table is part of the solution — is handled in IGW-NET through 2–3 quick linear simulations that derive layer geometry from the water-table solution itself, converting a nonlinear problem into a strictly confined sequence of linear ones. Surface-water features — rivers, lakes, wetlands — are represented through a five-way formulation taxonomy that the user steers per feature (LiDAR-emergent drainage for fragile and headwater features; head-dependent flux for major rivers; coupled water-balance for regulatory-target lakes and wetlands; full Saint-Venant coupling for streams in a future release). Together with streaming visual analytics that make the consequences of each conceptual choice visible during the simulation itself, this is what allows the aquifer dynamics on the IGW-NET side to resolve correctly — and what makes the ecosystem-scale outcomes above operationally producible rather than aspirational. Documented in the IGW-NET Users' Manual.
See IGW-NET L2 § "Free surfaces, surface-water features, and steering" for the full architectural treatment.
IGW-NET begins as a 2D base model. Users add computational layers to improve vertical-flow accuracy where vertical gradients matter. Users add conceptual layers to represent distinct hydrostratigraphy where it matters. The base model has instant-generating capability for all of this — adding layers happens within the same generative framework, no rebuild, no remesh from scratch.
Watershed modeling becomes discovery.
The problem isn't lack of data — the field has built an extraordinary watershed data infrastructure across decades, agencies, and open-source communities. The problem is rebuilding what already exists, basin by basin, instead of using it to understand watersheds intelligently. SwaNET turns watershed modeling into a continuous, network-grounded discovery process — one that honors the work the field has already done, and lets your own work join the network.