What IGW-NET Is and When to Use It

1.1 What IGW-NET Is

IGW-NET is the groundwater platform within the MAGNET4WATER water-intelligence ecosystem — the flagship of five sister platforms (IGW-NET for groundwater, SwaNET for watersheds, StormNET for urban water and rivers, ConduitNET for water distribution, DataNET for federated data services and fusion). This manual covers IGW-NET in depth; the other platforms have their own documentation, and the MAGNET4WATER website covers the full ecosystem.

Within its domain, IGW-NET lets you build a working simulation of how water moves beneath the land in a place you care about — a watershed, a property, a region where you're considering a well, a site you're studying, a community you're planning for.

What makes it distinctive is that a working model exists the moment you draw a domain. You do not assemble the model piece by piece before running it. You sketch a rectangle on a web map, and IGW-NET — drawing on the MAGNET4WATER Global Base Model (a pre-assembled global foundation of terrain, geology, recharge, and climate data), typical parameter values chosen for numerical robustness, and a pre-wired solver — immediately has a complete, runnable simulation ready. Often 80–90% of a new model is already built from the Global Base Model; your job is to refine the remaining 10–20% with local data and domain expertise. Click SIMULATE and you see head contours, velocity vectors, a water balance, cross-sections, and 3D views of the water table.

From that starting point — which Chapter 5 calls the base model — you refine. Replace default parameters with your site-specific values. Switch from typical hydraulic conductivity to a Data Center raster specific to your region. Upload your own DEM. Add pumping wells, contamination sources, lakes, streams. Each change is immediately reflected in the visualization. The platform was designed for this refinement-first workflow: you are not "setting up" a model from scratch; you are shaping one that already works.

Under the hood, IGW-NET combines multiple industry-standard solvers into a single unified interface. For groundwater flow, the platform uses the MODFLOW family — MODFLOW-6, MODFLOW-2005, MODFLOW-USG, and MODFLOW-NWT — plus the Interactive Groundwater (IGW) solver for real-time streaming simulation. For solute transport, MT3DMS is integrated with support for multi-species reactions, chain reactions, and dual-domain formulations for fractured or strongly heterogeneous media. For variable-density flow — seawater intrusion, brine migration, thermal plumes — SEAWAT is integrated within the same streaming framework. What users experience on the surface is a map, a drawing tool, a single dialog for aquifer attributes, and a rich visualization stack. The mathematics is handled for you.

The platform is also fundamentally real-time and streaming. Simulations are not static batch jobs — you watch flow fields, plumes, and particles evolve as an animated movie while the solver advances. You can computationally steer the simulation mid-run: change a parameter, add a feature, re-simulate, watch the change propagate. This is why the platform is designed around default-running-then-refining rather than configure-then-run.

1.2 Who Benefits From Using IGW-NET

The platform serves a broad range of users — not because it's generic, but because groundwater affects many kinds of work. Here are the people who most commonly find IGW-NET valuable, and what they use it for.

1.3 What IGW-NET Does Well

Four capabilities define the platform. These are where you get real leverage — the things that would take days or weeks of work in other tools and take minutes in IGW-NET.

1.3.1 End-to-end simulation from click one

The moment you define a model domain, a complete, runnable groundwater simulation exists — with aquifer top, bottom, hydraulic conductivity, recharge, porosity, storage, and surface drainage all set to reasonable defaults. You do not configure these before running. You run first, see the solution, and then refine progressively — adding complexity only where it changes the answer. This inversion — from "set up then solve" to "solve then refine" — is the platform's most distinctive design choice, and it reflects a core modeling philosophy: the model guides data collection, the data improves the model, and each iteration is sharper than the last.

And the simulation is not just flow. Add a concentration source and transport activates automatically — you get an animated plume. Drop a zone of particles on the flow field and they animate along the velocity vectors. The water balance is tabulated. Cross-sections colorize themselves. The 3D water table is a single click away.

1.3.2 A visual sandbox — synthetic and georeferenced modes

IGW-NET runs in two modes, and both are first-class. Georeferenced mode is what most of this manual focuses on: you point the platform at a real location, the Global Base Model loads real DEMs, real K rasters, real recharge, real streams and lakes, and you build a model of a specific place. Synthetic mode is the other canonical use — an empty canvas, no real coordinates, where you draw a concept and immediately see what it means. The interface switches you to a blank spot for synthetic work. Both modes use the same solver, the same features, the same visualization. What differs is only whether the domain is tied to real-world geography.

Synthetic mode is not a toy. It is how a large share of serious modeling actually happens — consultants scoping a problem before committing to a full site model, researchers testing a hypothesis about heterogeneity or coupled dynamics, professors teaching the physics of groundwater flow, students exploring concepts as fast as they can think of them. The synthetic canvas is a blackboard with physics attached. What you draw, you simulate. What you change, you see respond. The thinking happens at the speed of sketching.

Cross-section work is equally direct. You can draw a profile and model it with the same governing equation that applies in plan view. In the vertical profile, anisotropy (horizontal K ≫ vertical K in most aquifers) usually cannot be ignored — but if you vertically exaggerate the profile by the transform factor √(K_x/K_z) the profile becomes effectively isotropic in the transformed coordinate, which is why modelers routinely display vertical sections with that exaggeration. You can also draw a curved upper boundary representing a water table. The water table is, by definition, the surface where pressure equals zero, so water-table head equals elevation — in two dimensions, head = y. IGW-NET lets you assign head = y along a drawn boundary to represent an actively-shaped water table. You see regional vertical circulation emerge from the topography of that boundary in real time. Draw a sloping water table and Tóth's regional-flow patterns appear — local, intermediate, and regional flow cells stacked vertically. Draw a wavy, sinusoidal water table representing topographic relief, and the nested flow systems appear just as in the classic papers. Add an internal horizontal layer of contrasting K — a high-K basal sand unit, or an intermediate low-K aquitard — and you see extended Tóth behavior: water self-optimizes its pathways through the structural geology, routing preferentially through high-K zones, pooling above aquitards, and producing the complex recharge-to-discharge patterns that real glaciated aquifers exhibit.

This prescribed-water-table approach is unmatched for visualizing flow geometry, but it has an important limitation — the simulated fluxes are only physically realistic when the drawn water table and the assigned K field are mutually compatible with available recharge. A steep water table paired with high K will produce enormous fluxes that could not possibly be supplied by rainfall. When flux realism matters — for water-budget analysis, recharge estimation, or site-specific inference — use the 3D-slice approach instead: a narrow one-cell-wide plan-view strip with full vertical resolution, the DEM as the top, and recharge as the input; the water table then emerges as a solution that is by construction consistent with rainfall. Chapter 10 §10.2 covers both approaches in depth, including when to use each.

Used this way, the platform is a thinking instrument. The time from question to insight collapses. Visualizing what heterogeneity does to transport, what a sloping water table does to regional flow, what a pumping well does to a coastal lens — each takes minutes, often less. The physics is not simplified; it is the same governing equations and numerical schemes that run in the georeferenced case. What synthetic mode removes is the data-preparation overhead, so that the full attention can go on the concept.

1.3.3 Data Center and DataNET — no GIS wrangling

A library of curated spatial datasets is built into the platform. Hydraulic conductivity rasters for Michigan, the USA, and globally. Bedrock elevation. Long-term mean recharge. DEMs at 1 m, 10 m, 30 m, and 90 m resolution. Precipitation and climate data. Static water levels from dense statewide water-well databases. USGS sensor data for transient calibration. Borehole lithology data for 3D geologic modeling. Instead of downloading, reprojecting, and clipping each layer, you pick from a dropdown. The platform handles the spatial operations behind the scenes.

Beyond the built-in Data Center, IGW-NET includes a direct bridge to DataNET web services — WMS, WFS, and WCS layers organized by region and environmental category in a multi-scale Data Tree. You can also import from external or third-party web data servers, making any OGC-compliant data source available for model parameterization. And when you have better local data than any online service offers — site-specific K from aquifer tests, project-specific recharge, custom borehole logs — you upload your own raster, shapefile, or borehole logs, and the platform uses your data in place of the defaults.

A particularly powerful example of the DataNET architecture is LiDAR DEM delivery. LiDAR coverage for all of North America is available from USGS WMS/WCS services, but LiDAR datasets for any sizable region are genuinely massive — impossible to move as local files, and difficult to handle in platforms that require manual DEM preparation. IGW-NET resolves this by streaming LiDAR through DataNET on demand, with automatic subsampling by area: for a large regional domain, the subsampled resolution is appropriate to the grid; for a small local domain, the original 1 m resolution is preserved. The model file stays light because the data stays virtually immobile on the server. Combined with hierarchical modeling (Chapter 13), this means a regional parent model with standard DEM and a fine-resolution submodel with LiDAR over an area of interest is a practical everyday workflow rather than a data-management project. It's one of the concrete ways the platform removes logistical barriers that would otherwise limit what a single modeler can do. A flagship application is headwater groundwater-dependent ecosystems — fens, hanging bogs, coldwater headwater reaches, wetland complexes where small topographic features control where groundwater emerges and which wetlands are GW-fed. Classical workflows with 10 m or 30 m DEM cannot resolve the topography that controls discharge in these settings; LiDAR with hierarchical modeling makes the modeling tractable, and Chapter 22 §22.2.5 develops this in detail. The customization ladder (Chapter 5) formalizes how this progressive refinement works.

1.3.4 Instant local refinement via submodels and unstructured grids

When regional resolution isn't enough for a specific question, you don't rebuild the model at a finer grid. You draw a box inside the parent domain, check "Boundary Condition from Parent Model," and you have a refined local model whose boundaries inherit from the regional solution. The whole operation takes about a minute. Chapter 13 covers this in depth; the point for now is that local refinement in IGW-NET is a one-minute operation, not a multi-day rebuild.

When refinement needs are even more specific — a pumping well, a stream, a small plume source — IGW-NET also supports unstructured grids: rectangular cells of varying size, with refinement concentrated where head or concentration gradients change rapidly. You can generate refinement zones inside the platform, or import them from an external shapefile. Unstructured-grid results display on the same map and feed the same cross-section, water balance, and particle-tracking tools as structured-grid results. See Chapter 19 for the MODFLOW 6 DISV path that powers this.

1.3.5 Reactive transport, variable density, and multi-species

Transport in IGW-NET is not limited to simple conservative tracers. The platform integrates the industry-standard MT3DMS transport solver with support for:

• Multi-species reactive transport — track multiple interacting solutes simultaneously, including parent-child chain reactions (PCE → TCE → DCE → VC sequential degradation), interspecies reactions (electron donor / electron acceptor coupling), and predefined modules for common contaminants like BTEX (aerobic and multi-electron-acceptor kinetic decay pathways).
• Dual-domain transport — a mobile-domain / immobile-domain formulation that handles slow-tailing plumes in fractured rock, macroporous soils, and strongly heterogeneous aquifers where single-domain models fail. This is IGW-NET's effective approach to representing fractured-media transport without requiring a dedicated discrete-fracture-network solver.
• Variable-density flow and transport via the integrated SEAWAT engine. Saltwater intrusion in coastal aquifers, brine migration from injection wells or evaporite dissolution, and thermal plumes from geothermal or industrial sources all run within the same streaming framework as standard flow.

All of these run in the same end-to-end pipeline as the base model — plumes animate in real time, concentration breakthrough at monitoring wells is charted as the simulation advances, and you see both head and concentration fields updating together. Chapters 11 and 12 cover transport in depth.

1.3.6 Stochastic and uncertainty quantification

Real aquifers are heterogeneous at scales smaller than any grid can resolve. IGW-NET addresses this with built-in stochastic tooling — not as an afterthought, but as a first-class capability. Two complementary approaches:

• Sequential Gaussian Simulation (SGS) — generates spatially correlated random K fields with user-controlled mean, variance, and correlation structure. IGW-NET runs full Monte Carlo simulations across hundreds or thousands of realizations, computing ensemble statistics on the fly: mean head and plume fields, variance maps, probabilistic capture zones, probability of MCL exceedance at monitoring points, and live-streaming hydrographs across realizations. This is made possible by the platform's never-accumulate architecture (see callout below).
• Transition Probability (T-PROGS) geostatistics — generates discrete geologic realizations from borehole records, with multiple material categories (e.g., aquifer / marginal-aquifer / partially-confining / confining) each with characteristic K values. For T-PROGS, users simulate one realization at a time; ensemble analysis is manual rather than automatic.

Monte Carlo forward and reverse particle tracking generates probabilistic capture zones and influence zones. Together these tools move IGW-NET from deterministic single-answer modeling to risk-based, uncertainty-aware prediction. Chapter 18 covers stochastic modeling in depth.

1.3.7 Calibration with big data

Calibration in IGW-NET is designed around the reality that most modelers today have access to dense but noisy statewide water-well databases — thousands of static water-level measurements per region, of variable quality. The platform handles this through two integrated paths:

• Manual calibration with multipliers — adjust K or recharge multipliers while watching the calibration scatter plot update in real time. Because multipliers preserve spatial structure while shifting overall level, calibration stays defensible (see Chapter 5 §5.5.4 for why this matters).
• Automated parameter optimization via UCODE — nonlinear-regression inverse modeling (Poeter and Hill, 1999) integrated directly into the platform. Observations to match: heads, fluxes to surface-water bodies, concentrations. Parameters that can be optimized: recharge and K multipliers, anisotropy ratios, specific yield and specific storage, river/stream/lake leakances, and drain leakances. No separate installation, no input file editing.

USGS time-series sensor data can be extracted directly for transient calibration — or used for steady-state calibration by comparing average, maximum, or minimum observed water levels to simulated heads. Chapter 17 covers calibration in depth.

1.3.8 Collaborative modeling — unique among platforms

Because IGW-NET is cloud-native, it enables something that desktop modeling tools cannot: multiple users working live on the same model simultaneously, from anywhere in the world. When you sign up, you are prompted to invite collaborators or add guest accounts; those collaborators can then edit the same domain, zones, features, and attributes you are editing, with all changes visible to every user in real time. When any user clicks SIMULATE, all users see the results simultaneously.

This matters in several contexts:

• Student team projects. Teams no longer need to coordinate schedules around a shared computer lab. Students in different dorms, different cities, or different countries can work on the same model synchronously — typically while on a video conference — just as if they were sharing a laptop.
• Distributed consulting teams. A regional hydrogeologist, a project lead, and a regulatory reviewer can inspect the same model together, in real time, from three different offices.
• Peer learning and mentorship. An instructor can watch a student's work as it unfolds and intervene in real time; a senior modeler can demonstrate techniques to several juniors at once.

This is distinct from asynchronous collaboration through the MAGNET4WATER Observatory (Chapter 2 §2.5), where published models are shared for others to download and extend on their own time. Synchronous collaboration makes IGW-NET a real-time shared workspace, not just a shared library.

1.4 What IGW-NET Doesn't Do

Honest positioning requires being clear about fit. IGW-NET is a broad platform, but it is not universal. Here are the situations where another tool is a better choice.

1.4.1 The ZipMODFLOW post-analysis bridge

For externally-built MODFLOW models — whether from another platform, a published study, or a legacy project — IGW-NET offers the ZipMODFLOW post-analysis tool. Load an existing MODFLOW model, run it inside the platform, inspect boundary conditions, draw cross-sections, perform basic calibration, run MODPATH particle tracking, and more. This is how users bridge existing MODFLOW workflows with IGW-NET's visualization and analysis capabilities without rebuilding the conceptual model.

1.5 The Core Vocabulary

A set of terms threads through this manual and the MAGNET4WATER ecosystem. Learning them now makes the rest of the manual — and the wider website — easier to follow.

1.5.1 Conceptual model (xyz) vs numerical model (ijk) — the foundational distinction

More than any other concept in this manual, the distinction between the conceptual model and the numerical model is the idea that unifies how IGW-NET works. Understanding it will make every subsequent chapter click into place.

The conceptual model — what you build in xyz

The conceptual model is your representation of the real-world aquifer system, expressed in continuous spatial coordinates (xyz — longitude, latitude, elevation, or projected equivalents). It includes:

• The domain boundary you drew on the map
• Every zone you added (with its K, recharge, porosity, and other attributes)
• Every polyline you drew (rivers, streams, drains) with their type and attributes
• Every well (pumping or injection) with its coordinates, flow rate, and screen depth
• The conceptual layers representing geologic units
• Any particles you placed for tracking
• Any concentration sources you defined

This is the faithful xyz representation of how you understand the site. Features sit at their real coordinates. A river runs along its true path. A well is at its actual location. Zone boundaries follow the geology as you understand it. This is the model you build and maintain — and the model you can freely edit at any time.

The numerical model — what the solver sees in ijk

The numerical model is a grid-based approximation of the conceptual model. It uses discrete cells indexed by row (i), column (j), and layer (k) — MODFLOW's standard convention. Each cell has one K value, one head value, one concentration value per species, one velocity vector. The solver operates entirely on this ijk representation — solving the flow PDE on the grid, computing cell-to-cell fluxes, integrating through time.

The numerical model is always an approximation of the conceptual reality. A river that traces a sinuous path in xyz becomes a staircase of cells in ijk. A zone boundary that follows a geological contact gets snapped to the nearest cell edge. A particle at some xyz position gets located within a specific ijk cell to determine its velocity. How close the ijk approximation is to the xyz reality depends entirely on grid resolution — which is why this distinction matters.

Discretization — the xyz → ijk mapping, happens at SIMULATE

Every time you click SIMULATE, IGW-NET performs discretization: it reads your conceptual model and maps every feature onto the grid to build the numerical representation. Zones get rasterized onto cells; polylines become sequences of cells; wells get located in their cells; attributes get averaged over cell footprints. This mapping happens completely automatically — you never see or touch the grid directly.

Because discretization happens at SIMULATE time from the current conceptual model, you have a powerful working mode: edit the conceptual model freely, then simulate to see the consequences. The conceptual and numerical models are not linked one-to-one; they are linked by the discretization operation, which repeats every time you simulate.

Nested models — hierarchical ijk for a single xyz reality

For a single regional domain, IGW-NET's grid has one resolution — and a grid fine enough to resolve every local feature would be prohibitively large if applied to the whole region. The standard answer is nested modeling: a coarse regional grid that captures the xyz context, with one or more finer local grids (submodels) covering the areas where detail matters. Each submodel inherits boundary conditions from its parent, so the local simulation sees the regional flow while resolving local features at a resolution the parent cannot.

In IGW-NET, creating a submodel is a straightforward operation: draw a rectangle around the area of interest, flag it as a submodel boundary, and enable boundary-condition inheritance. You can recursively create further sub-submodels for even finer resolution in smaller areas. In principle, a hierarchy of models can cover a very large area with faithful local detail everywhere, because each level is computationally light.

The deeper reason hierarchy matters: nested modeling is not just a numerical efficiency trick. Hierarchical organization is the right framework for modeling, assimilation, visualization, and data transmission simultaneously. Many small models solve more robustly than one big monolithic model (numerical). Humans assimilate multi-scale information hierarchically, not as flat pixel fields (cognitive). Different stakeholders — regulators, site managers, plume engineers — need different levels of detail for their decisions (management). And hierarchical data transmits efficiently over the internet while monolithic models don't (infrastructure). Even when a machine can solve a monolithic model, humans cannot readily assimilate its output, organizations cannot easily coordinate around it, and networks cannot efficiently transport it. Hierarchy is how multi-scale information wants to be structured — for machine tractability, for human comprehension, and for collaborative infrastructure. See Ch. 13 §13.5.1 for the full argument.

The working pattern: the xyz conceptual world is what you care about; the ijk numerical representation is how you compute; nested models let you vary the ijk resolution to faithfully represent xyz wherever fidelity matters — while keeping the entire representation structured as the hierarchy that humans, machines, and networks all prefer. Chapter 13 covers nested modeling in depth.

A few more terms worth knowing up front:

• Customization ladder — the seven-rung refinement progression for every attribute: typical default → your constant → Data Center raster → your uploaded raster → DataNET service → scattered points → T-PROGS 3D geology. You climb only where visualization shows you need to. See Ch. 5 §5.2.
• Data Center — the built-in library of curated spatial datasets (hydraulic conductivity, bedrock, DEMs, recharge, climate), selected via dropdowns in the platform and looked up per-cell at simulation time.
• DataNET — the fifth MAGNET4WATER platform and the live bridge between IGW-NET and federated web data services (WMS, WFS, WCS) organized in a hierarchical Data Tree. Extends the built-in Data Center with external and third-party data. See Ch. 22.
• Submodel — a refined local model nested inside a parent regional model. Draw a box, check one option, the submodel inherits boundary conditions from the parent. One-minute operation. See Ch. 13.
• Zone — a polygon you draw inside your domain to override attributes locally. Inside a zone, zone values take precedence; where silent, the domain fills in. Zones unlock refinement options (scattered points, T-PROGS) not available at the domain level. See Ch. 5 §5.10 and Ch. 6.
• Intelligent Reporting System — the automated model-description generator. Reads your model file and produces a human-readable report describing assumptions, parameter choices, and suggested refinements. Every model published to the Observatory is accompanied by such a report.
• Collaborative workspace — the live multi-user modeling mode. When you sign up, you can invite collaborators or guest accounts who edit the same model synchronously from anywhere in the world. Distinct from asynchronous sharing through the Observatory.

1.6 How This Manual Is Organized

This manual is one of six complementary documentation resources for IGW-NET, each serving a different question. Knowing when to reach for which saves time.

1.6.1 The parts of this manual

1.6.2 The other five documentation pillars

This manual sits alongside five other resources, each answering a different kind of question: