🌊 SwaNET · Beginner Tutorial

Build your first watershed model in one click.
Then refine what matters.

SwaNET does the heavy lifting — terrain, soil, land use, climate, stream networks, HRUs, simulation, visualization, monitoring data — so a working watershed model arrives in minutes. The model is the starting point. You spend your time on what changes the answer: refinement, comparison, calibration, scenarios.

SwaNET Tutorial S8 · Beginner-friendly · 10 steps · ~15 min walkthrough · Worked example: Kalamazoo River Watershed, Michigan

Quick simulate

Draw a box. Defaults run. A working model in minutes.

See what matters

Sankey, water balances, 3D, streamflow — read the regime.

Compare with reality

Pull USGS / Canada gauges. Overlay observed on simulated.

Refine where it counts

Resolution, HRUs, weather, calibration — all in the loop.

Why one-click

The heavy lifting is already done.

Conventional watershed modeling spends weeks on data assembly before the first simulation. SwaNET inverts this. Pre-processed multi-resolution data is already on the network. Watershed and subbasin delineation, stream networks, land use and soil extraction, HRU computation, weather generation, SWAT input writing, and the simulation itself — all are automated inside the platform.

The first model is reasonable, detailed, and ready to interpret in a few minutes. It is not the final model. It is the starting point that frees you to do the work that actually changes the answer: experimentation, scenario testing, model-data comparison, management interpretation.

Terrain + streams

Snapped outlet

Watershed + subbasins

Land use

Soil type

HRUs

System Water Balance Sankey diagram showing rainfall, snowmelt, ET, runoff, percolation, baseflow, and outlet discharge as proportional flow widths

Signature — system water balance Sankey

Part 1 · The first model

Quick simulate. Defaults everywhere.

Four steps from login to a working watershed model. The example is the Kalamazoo River Watershed in southwestern Michigan, but the workflow is the same for watersheds across the United States, Canada, and most regions worldwide where the underlying data services are available.

Zoom in. Draw the box.

Define the watershed region on the map.

Login to SwaNET. Zoom into the region of interest. Create a new project, draw a box on the map covering the watershed, and save the shape.

Click path

Load Model›Create a New Model›follow on-screen prompts›Draw Shape›[define box on map]›Save Shape›Select model options

💡

Concept

The box defines a region. SwaNET will delineate the actual watershed and subbasins from terrain automatically — the box just tells the platform where to look. Draw a box that comfortably contains the watershed you have in mind.

Zoom from the US down to southwestern Michigan, with the Kalamazoo River Watershed region highlighted — Zoom into the region of interest.

SwaNET Select DEM dialog showing the Draw Shape and Save Shape buttons, with a box drawn on the map containing the watershed — Draw a box that contains the watershed. Save the shape.

Apply defaults

Use coarse-resolution defaults for everything.

For the first model, accept every default. Defaults are calibrated starting values — well-chosen, sensible, and fast.

Watershed delineation — terrain (DEM) and stream area threshold
Land use and soil maps — default resolution
HRU creation and selection — automatic
Weather generator — automatic file

Then

Build Model — starts the building and simulation

⚙️

Why defaults first

The default model is intentionally coarse-resolution so it builds and runs quickly. It will not be the most accurate model possible — but it will be a reasonable, complete model that shows you what the watershed looks like dynamically. That is enough to start asking the questions that matter.

📐

What SWAT actually computes — a system of connected buckets

Here is the whole model in one picture, nested in two levels. The watershed is a network of subwatersheds, each a real drainage cell, connected outlet-to-outlet by the channel network. And each subwatershed is itself a network of connected storage buckets — soil, aquifers, channel. The water balance — in − out = change in storage — is applied to every bucket, and the buckets are wired together so one bucket’s outflow is another’s inflow. What matters most is not any single number but the relative sizes of the flows between buckets and between subwatersheds — that pattern is the watershed’s behavior. Get the pattern right and the model is sound (and far easier to calibrate); get it wrong and no amount of parameter-tuning will save it.

Inside a subwatershed, the buckets — following a raindrop:

Soil profile (top ~2 m) — rain and snowmelt arrive here; water leaves as evapotranspiration (up), surface and lateral flow (sideways to the stream), and percolation (down). Snow is held in a snowpack bucket until it melts.
Shallow aquifer — fed by percolation; releases water slowly to the stream as baseflow (what keeps rivers running between storms), with a little returning up to the soil.
Deep aquifer — a near one-way exit: water here is considered lost to regional groundwater outside your basin.
Channel — collects runoff, lateral flow, and baseflow, then carries them to the subwatershed outlet. Ponds, wetlands, and reservoirs are optional on/in-channel buckets, off by default.

Three scales organize the inner network. Weather is shared at the subbasin scale (every HRU in a subbasin gets the same rainfall). Land-surface fluxes are computed per HRU — each unique land use × soil × slope combination — so the response is accurate across varied land; HRUs are flux-computation devices, not map units. The water balance closes at the subwatershed. Then, at the outer level, no water crosses between subwatersheds on land — the channel network is the only link, carrying each subwatershed’s outflow downstream to the next via fast, hydrologically-based routing (not grid-based hydraulic momentum). That is exactly how real watersheds behave, which is why the structure is both faithful and fast.

SwaNET wires all of this automatically from the terrain, soil, and land use it extracted — you don’t set up a single bucket or connection by hand. You are not giving up control; you are starting from a sound default you can inspect and adjust later. The Sankey you’ll read shortly is the system view — the whole watershed’s buckets and flows aggregated into one map.

SwaNET One-click Model Options panel with default settings — 300m DEM, 400m land use and soil, target HRU number, WGEN_CFSR_World weather generator, and the Build Model button — The One-click Model Options panel. Accept every default and click **Build Model**.

Wait — but not for long

SwaNET builds and runs the model.

Wait a few minutes. During this time, pre-processed big data for the model area is extracted, all model input files are created, and the simulation runs — model building and visualization happen automatically.

📋

What's happening behind the scenes

Extracting terrain · delineating the stream network · delineating subbasins and watershed · auto-snapping the outlet to the largest drainage stream · extracting land use · extracting soil · creating HRUs · generating weather files · writing SWAT input files · running the SWAT simulation · processing and visualizing results.

SwaNET status message: Creating a new SWAT model. This process will create a SWAT model, run it and display water balance maps and 3D view. Please sit back and relax as it might take a while. — SwaNET handles the model building, simulation, and visualization automatically.

The model is ready

Inspect outputs — read the regime.

Once the simulation finishes, results appear automatically in the map display and pop-up interfaces. Three views show themselves first — each answers a different question.

Other inspection tools

Simulation/Visualization›Result Visualization

Utilities›Map options

Click any subbasin marker for subbasin-based plotting

📅

Simulation time period

Automatically assigned based on data availability: the latest five years if available, or 1990–1991 with 1990 as spin-up year if not.

SwaNET auto-displayed output dashboard: subbasin map with markers, 3D watershed view, water balance diagram, and streamflow time-series chart — The model is ready. Map view, 3D watershed, water balance, and streamflow time-series — all displayed automatically.

What the platform shows you

Three views. One model.

SwaNET's auto-displayed outputs aren't a generic dashboard — each view is a different lens on the same simulation, designed to answer a different question. Read them in this order.

SWAT Water Balance Sankey diagram showing rainfall, snow melt, evapotranspiration, runoff, baseflow, and stream discharge with quantitative flow values

🌊

Signature

Sankey · System water balance

A complete, quantitative description of all inflows, outflows, and stocks in the watershed — and how they connect. The watershed's hydrologic fingerprint in one image. If the simulation spans multiple years, multiple Sankey diagrams are produced.

⏱️

Time

Streamflow time-series

Streamflow at the watershed outlet over the simulation period. Reveals the regime — base-flow dominance, flashy response, seasonal pattern, peak timing. This is where observed data will overlay once you load gauge stations.

SwaNET 3D watershed visualization — the Kalamazoo basin rendered as textured terrain with elevation coloring, stream network, and subbasins on an interactive 3D surface

🗺️

Space

3D watershed visualization

Watershed, subbasins, stream network, snapped outlet, land use, soil, HRUs — rendered as live textures on an interactive 3D terrain. Reveals where the action is spatially.

🔍

Read the Sankey first

The three views answer different questions, but the Sankey is the one to read first. It tells you whether the model produces a watershed that resembles your intuition — and where it doesn't. Skip ahead to "The Sankey, explained" below before opening any other view.

How to read what SwaNET shows you

The Sankey, explained.

The system water balance Sankey is the watershed's hydrologic fingerprint — the system view of the bucket network from the previous section, with every subwatershed’s buckets and flows aggregated into one map of the whole watershed. Each band's thickness is drawn in proportion to how much water flows along that path over the simulation period. In one picture it answers: where did water come from, what happened to it, where did it go, and which pathways matter most. The values are real outputs from your SWAT simulation. Learning to read it is the single most useful skill for SwaNET work.

SWAT Water Balance Sankey diagram for the Kalamazoo River Watershed (5172 sq. km, 1991): rainfall 763.5 mm, snowmelt 331.9 mm, evapotranspiration 532.9 mm, surface flow 269.4 mm, baseflow shallow 242.7 mm, discharge to outlet 523.5 mm, all units in mm of water depth over the watershed area — Kalamazoo River Watershed, calendar year 1991. All values in millimetres of water depth over the 5172 km² watershed area.

↦

Read it left-to-right

Inputs · Processes · Outputs

Water enters on the left — rainfall, snowmelt, initial soil moisture, irrigation. It passes through land-surface processes in the middle — evapotranspiration off the top, infiltration and percolation downward, runoff into the stream network. It leaves on the right — discharge out of the watershed outlet, deep aquifer storage, reservoir outflows. The widths of the bands are proportional to the volume of water moving through each pathway.

📅

It's a volume over a period

Water in · out · stored

Every number is a total volume of water for a chosen period — by default the entire simulation. The left side sums all water that came in, the right side all that went out, and the difference is what changed in storage over that period. Change the period and the picture changes: a wet year and a dry year produce different fingerprints. (If the run spans multiple years, SwaNET produces a Sankey for each.)

📏

Thickness tells you what matters

Read the number on each thread

Thread thickness is strictly proportional to the number on it — nothing more. The thinnest threads carry zero (a process not represented in your model); thicker threads carry more water. But here's the catch: a tiny non-zero flux is technically thicker than zero, yet your eye usually can't tell them apart. That visual sameness is itself informative — if a represented process is so thin it looks like zero, it behaves practically the same as if it weren't there at all. The number is how you tell the two cases apart: zero means you left it out; a small-but-nonzero number means you included it and it turned out negligible. If a thin thread matches your understanding of the watershed, fine — don't sweat its parameters. But if a process you believe should matter is reading near-zero, that mismatch is a red flag worth investigating, not something to wave past.

🔎

Your job: do the numbers make sense?

Assess before you calibrate

Before touching calibration, read the magnitudes against your own qualitative picture of the watershed and ask: are the relative sizes physically sensible, and are the processes that matter for my question carrying the water they should? It's the relative magnitudes — the flows between buckets — that matter, far more than any absolute number. Get the relative pattern right and calibration becomes much easier; the parameters are then just fine-tuning, not a rescue. Where the Sankey matches your understanding, you gain confidence. Where it contradicts it — ET too thin for a humid basin, a process you know is active reading near-zero — that mismatch is the most valuable thing on the screen: it points to a flaw in the conceptualization, the inputs, or a parameter, and tells you exactly where to iterate. You use the Sankey to steer. Calibration tunes parameters; it cannot rescue a model built on the wrong processes. Modeling is not turning the crank; it is building understanding, and the Sankey is the instrument that makes that understanding visible.

🎚️

This is what modeling is

Represent what the question demands

Good modeling does not mean representing every possible process — it means representing the ones your question actually needs, and consciously leaving out the rest. The Sankey keeps you honest about that judgment: read the numbers and you can see exactly which processes carry real water and which sit at or near zero. A process you left out reads zero; one you included but that turned out negligible reads a tiny number — and practically, both tell you the same thing about where not to spend effort. As your question evolves — add irrigation, a reservoir, observed weather — a thread that was zero or negligible can grow into a real, thick pathway.

⚖️

The closure principle

Inputs = Outputs ± ΔStorage

A watershed obeys conservation of mass: water in equals water out, plus or minus any change in storage. The Sankey makes the books visible. Note the small "Overland error" band — that's the model's residual closure error. A few percent is normal numerical drift; a large residual suggests configuration trouble. The Sankey lets you check the books at a glance.

🌡️

Patterns to spot

What the proportions reveal

ET fraction — humid-temperate watersheds typically return 50–70% of precipitation to the atmosphere; arid systems return 80–95%. Runoff vs baseflow — flashy urban systems are runoff-dominated; groundwater-fed rural systems are baseflow-dominated. Deep percolation — high values mean recharge to regional aquifers, important for groundwater sustainability questions.

🧠

Before you calibrate, understand the Sankey

Calibration adjusts parameters to fit observed streamflow at the outlet. But streamflow is the integrated output of dozens of processes — different parameter combinations can produce the same hydrograph with very different underlying water budgets. The Sankey shows whether the right processes are dominant at the right magnitudes for your watershed type. Calibration without understanding the Sankey can find a fit that's right for the wrong reasons. The Sankey is your diagnostic check against equifinality — the principle that very different models can produce equally good fits.

Deeper diagnostic

Water balance at four scales.

Beyond the system Sankey, SwaNET's drop-down menus let you inspect the water balance bucket by bucket — the same connected storage buckets introduced earlier (land surface, shallow aquifer, deep aquifer, channel). SWAT's strength is that it keeps separate books for each compartment, and SwaNET makes every one of those books visible. Watch how the outflow of one bucket becomes the inflow of the next: percolation leaving the overland balance reappears as recharge entering the shallow aquifer; baseflow leaving the aquifer reappears as inflow to the in-stream balance. The values are pulled live from your simulation.

SWAT Overland Water Balance diagram: rainfall 699.4 mm, snowmelt 171.5 mm, evapotranspiration 523.9 mm, percolation 209.1 mm, overland flow 151.5 mm, lateral flow 2.4 mm, with bar chart at bottom showing inputs (blue) and outputs (red) — **Overland** — the land surface and root zone. Rainfall and snowmelt enter; ET, percolation to the shallow aquifer, and surface plus lateral flow to streams leave. This is where most of the action happens hydrologically.

SWAT Shallow Aquifer Water Balance: recharge 209.1 mm in, baseflow to streams 192.4 mm out, revap 21.4 mm, percolation to deep aquifer 10.5 mm, storage change 15.2 mm — **Shallow aquifer** — the unconfined water-table aquifer. Receives recharge from the vadose zone; supplies baseflow to streams, revap (uptake by deep-rooted vegetation), and percolation to the deep aquifer.

SWAT Deep Aquifer Water Balance: recharge from shallow aquifer 10.5 mm in, deep baseflow 11.1 mm out, storage change 0.6 mm — **Deep aquifer** — the confined regional aquifer. Smaller fluxes by design; this compartment matters for long-term sustainability and groundwater discharge to receiving water bodies.

SWAT In-Stream Water Balance: surface runoff 151.5 mm, baseflow shallow 192.4 mm, baseflow deep 11.1 mm, lateral flow 2.4 mm, evaporation 6.4 mm, flow out 351.0 mm — **In-stream (reach-based)** — the channel network. Accumulates surface runoff, lateral flow, baseflow contributions, plus upstream inflows; loses water to channel evaporation, transmission loss, and downstream outflow.

📐

Why four scales matter for refinement

Each component balance has a different sensitivity to refinement choices. The overland balance is most sensitive to land use, soil, and HRU configuration. The shallow aquifer balance is most sensitive to groundwater parameters (GW_DELAY, GWQMN, ALPHA_BF). The deep aquifer balance responds to long-term recharge rates and is the slowest-moving compartment. The in-stream balance is sensitive to channel routing parameters and is where calibration against gauged streamflow happens. When the next steps refine resolution, land use, and HRU strategy, watch these four balances individually — that's where you'll see why the outlet streamflow changed.

Part 2 · Compare with reality

Pull observed streamflow. Overlay on simulated.

The first model runs on defaults — no observed data yet. The next four steps bring in real measurements from USGS or the Government of Canada monitoring networks and overlay them on the simulated time series. This is where you start seeing where the model gets the watershed right, and where it doesn't.

Extract observed streamflow

Pull USGS / Canada gauge data near the outlet.

SwaNET's Utilities menu provides direct access to the USGS National Water Information System and Government of Canada monitoring networks. Draw an extraction area near the watershed outlet, configure the pop-up, and extract.

Click path

Utilities›USGS/Canada monitoring data›Extract Data›[draw extraction area on map]›Save shape

In the pop-up interface:

Select 'Full Site Attributes'
Uncheck 'Groundwater'
Click 'Extract Monitoring Data'

Once extraction finishes, stations appear as numbered markers on the map. Click any marker to view its time-series streamflow and stage data.

Watershed map with extraction area drawn near the outlet, showing the subbasin coloring — Draw an extraction area near the watershed outlet.

Reload for refinement

Load the existing model for re-building.

You're not starting over — you're loading your earlier project to refine it with finer-resolution data and observed-streamflow comparison.

Click path

Load Model›Create a New Model›answer yes / OK to "Load latest project on server side?"›Watershed boundary›Select model options

Load Model dialog with the watershed boundary visible on the map and the Select model options button highlighted — Your latest project loads with the watershed boundary already drawn — ready to refine.

Two changes that matter

Switch to fine-resolution terrain. Pin the outlet to a real gauge.

Two targeted refinements: a finer DEM resolution for the watershed delineation, and a real USGS gauging station as the model outlet — so simulated and observed streamflow are at the exact same point.

Select '90m' from the drop-down next to DEM resolution
Click the chevron '>>>' next to 'Compare with US/Canada monitoring data' → 'Load Stations' → answer prompts to load the data from Step 5
Click marker for station USGS-04108670 → 'Create outlet'
Click 'Build Model' and wait

📐

Why this combination is the key move

Finer terrain produces a more accurate watershed delineation and finer subbasin structure. Pinning the outlet to a real gauge means simulated streamflow now corresponds exactly to where the observed data was measured. The model and the measurement are now at the same place. Comparison becomes meaningful.

One-click Model Options panel with DEM resolution set to 90m, station list showing USGS-04108670, and the watershed map with monitoring station markers — DEM resolution set to **90m**. USGS-04108670 selected as the model outlet. Then click **Build Model**.

The first comparison

Examine results — observed and simulated, side by side.

Once the updated model finishes, you'll see the typical outputs again — 3D watershed visualization, water balance charts — but now the observed streamflow data is added to the time-series chart, overlaid on simulated streamflow.

📅

Time period auto-adjusts

The simulation time period is automatically changed to match the observed data's temporal coverage. Necessary for direct comparison.

🎯

What to look for

Timing — are peaks happening on the right days? Magnitude — are flows in the right range? Recession — does the model drain at the right rate after a storm? Baseflow — is the dry-season floor right? Each kind of mismatch points to a different refinement.

3D watershed view alongside a streamflow comparison chart showing simulated and observed USGS-04108670 daily streamflow with NSE, PBIAS, and RSR fit metrics — 3D watershed view + simulated streamflow (blue line) vs observed USGS-04108670 (black dots). NSE, PBIAS, and RSR fit metrics quantify the comparison.

📊

Reading the fit metrics — NSE, PBIAS, RSR

The three numbers in the chart header are the standard model-fit statistics in hydrologic modeling, drawn from the Moriasi et al. performance guidance:

NSE (Nash-Sutcliffe Efficiency) — measures how well simulated values match observed variability. 1.0 is perfect; 0 means the model is no better than predicting the long-term mean; negative means worse than the mean. NSE > 0.5 is generally considered acceptable for monthly streamflow, > 0.65 good.
PBIAS (Percent Bias) — average tendency of simulated values to be larger or smaller than observed. 0% is perfect. Positive means the model underestimates; negative means it overestimates. |PBIAS| < 25% is generally acceptable for streamflow.
RSR (RMSE-to-Standard-Deviation Ratio) — normalized error magnitude. 0 is perfect. RSR < 0.70 is generally acceptable.

A first one-click model typically scores poorly on all three. That's expected — the metrics are your refinement compass, not a verdict on the platform. The next steps in this tutorial show how to move them in the right direction.

Part 3 · Refine where it matters

Test a hypothesis. Re-run.

Higher-resolution land use and soil maps, plus a different HRU selection methodology. Two more steps, and you have a second model to compare against the first.

Change land use, soil, HRU settings

Finer land use and soil. Different HRU strategy.

Load the latest project again. Navigate into HRU creation. Choose finer-resolution land use and soil maps, then change the HRU selection methodology.

Click path

Load Model›Create a New Model›yes / OK to load latest project›Model Creation›HRU creation

Choose '30m' for the land use map and the soil map
Click 'Extract' for each
After extracting, click 'Create HRUs'
Under New HRU Selection, select 'Dominant landuse, soil, slope'
Click 'Finalize HRUs'

🧩

What 'Dominant landuse, soil, slope' means

For each subbasin, SwaNET picks the single combination of land use, soil, and slope range with the biggest area in that subbasin and applies it to the whole subbasin. Coarser representation per subbasin — but one HRU per subbasin instead of many.

📝

Comparison with the original

The original model used 'Target number of HRUs' with a multiple of 4 of the number of subbasins. Example: 12 subbasins → target HRU = 4 × 12 = 48. The new selection produces one HRU per subbasin instead.

🧩

The HRU paradigm — a fundamental tradeoff

SWAT is a semi-distributed model: each subbasin contains one or more HRUs, and each HRU is a unique combination of land use, soil, and slope class. Water balance is computed per HRU, then aggregated to the subbasin and routed through the channel network. The HRU selection methodology shapes the model's representation of heterogeneity:

Target number of HRUs — preserves landscape diversity within each subbasin (multiple HRUs per subbasin). Better representation of small-area land uses (e.g., wetlands, riparian buffers) that may dominate hydrologic response despite small areal extent. More computation.
Dominant landuse, soil, slope — one HRU per subbasin, using the largest-area combination. Faster, simpler, but flattens within-subbasin diversity. The subbasin "speaks with one voice" hydrologically.
Filter by area / by land use, soil, slope threshold — middle ground, preserving HRUs above a threshold and merging the rest.

For comparison studies like this one, switching between these strategies isolates the impact of within-subbasin heterogeneity on the simulated water balance. Watch the four component balances after re-running — the differences reveal which compartments are most sensitive to HRU representation.

SwaNET HRU dialog with 30m land use and soil maps set to extract from server, plus the watershed with 30m land use overlay — Select **30m** for both land use and soil. Extract each. Then click Create HRUs.

SwaNET Final HRU dialog with 'Dominant landuse, soil, slope' selected and Finalize HRUs button visible — In New HRU Selection, choose **'Dominant landuse, soil, slope'**. Click Finalize HRUs.

Finish and run

Define the period. Re-run.

Follow the on-screen interfaces to:

Write SWAT input files
Define simulation period — back to 1990–1991 with one year of spin-up
Run the SWAT simulation

The updated results appear in the same display — but now you have two models to compare.

SwaNET Write SWAT input files dialog with the Write input files button highlighted — Write the SWAT input files.

SwaNET Simulation Options dialog with simulation period 01/01/1990 to 12/31/1991 and one year warmup, with Run SWAT simulation button highlighted — Set the simulation period (1990–1991 with 1990 as spin-up). Run SWAT.

Updated model results: 4-pane display showing daily water yield, daily evapotranspiration, daily precipitation time series, and a new watershed hydrology schematic with refined values (rainfall 760.4, ET 618.5, surface runoff 237.8, percolation 243.7), all overlaid on a watershed map with subbasins color-coded by water yield — The refined model's outputs. Compare the new watershed-hydrology schematic (bottom right) with the schematic from the first model — the same conceptual structure, but with quantitatively different fluxes. **Higher ET, lower runoff, larger percolation** — the consequence of 30m soil and land use plus the dominant-HRU strategy.

System water balance comparison

Same watershed, different model.

Original

First (one-click) model

DEM — default (coarse)
Land use — default resolution
Soil — default resolution
HRU strategy — Target number (4 × subbasins)
Outlet — auto-snapped

→

Updated

Refined model

DEM — 90m
Land use — 30m
Soil — 30m
HRU strategy — Dominant land use, soil, slope
Outlet — USGS-04108670 gauge

📊

How to see the comparison

Simulation/Visualization › Result Visualization › Plot water balances ››› › Plot. The simulated flows and stocks differ between the two models — and the differences are the quantitative impact of higher-resolution terrain, land use, soil, and the HRU selection methodology on your watershed's simulated dynamics.

Original

Updated

The base enables. It does not constrain.

You have built a watershed model in one click, read its hydrologic signature, compared it to observed streamflow, refined the resolution and HRU strategy, and identified three more refinement paths — all inside SwaNET, all in the same iteration loop. Time spent on data assembly: zero. Time spent on what matters: all of it.

Launch SwaNET → ← All SwaNET tutorials

Build your first watershed model in one click.
Then refine what matters.

The heavy lifting is already done.

Quick simulate. Defaults everywhere.

Define the watershed region on the map.

Use coarse-resolution defaults for everything.

SwaNET builds and runs the model.

Inspect outputs — read the regime.

Three views. One model.

Signature

Time

Space

The Sankey, explained.

Read it left-to-right

It's a volume over a period

Thickness tells you what matters

Your job: do the numbers make sense?

This is what modeling is

The closure principle

Patterns to spot

Water balance at four scales.

Pull observed streamflow. Overlay on simulated.

Pull USGS / Canada gauge data near the outlet.

Load the existing model for re-building.

Switch to fine-resolution terrain. Pin the outlet to a real gauge.

Examine results — observed and simulated, side by side.

Test a hypothesis. Re-run.

Finer land use and soil. Different HRU strategy.

Define the period. Re-run.

Same watershed, different model.

First (one-click) model

Refined model

Three more refinement paths. All in the same loop.

Change weather data

Edit subbasin data

Calibrate the model