MODFLOW Integration — IGW-NET and the Industry-Standard Engines

20.1 The Multi-Engine Architecture

IGW-NET is not "a MODFLOW GUI" in the traditional sense. It is a modeling platform whose interactive interface coordinates multiple industry-standard numerical engines, choosing the right one for each problem. This section establishes the architecture.

20.1.1 The engines IGW-NET uses

IGW-NET's solver stack currently includes:

All of these are USGS-published, community-validated engines. Using them gives IGW-NET results the same numerical credibility as any other platform using the same engines. The difference is that IGW-NET bundles them behind an interactive, integrated interface with automatic engine selection, rather than requiring users to assemble the stack themselves.

20.1.2 Automatic engine selection

Users typically don't choose engines manually. IGW-NET inspects model features and picks the appropriate solver:

• Standard structured grid, flow only: native IGW solver
• Unstructured grid with local refinement (refined wells, polylines, or zones in a nested-model setup): MODFLOW 6 with DISV discretization — automatically activated because the native solver doesn't handle unstructured grids
• Transport enabled: MT3DMS automatically added to the solve; flow engine handles groundwater flow, MT3DMS handles the solute
• Variable density: SEAWAT activated (solver position 17)
• Automatic Calibration: UCODE orchestrates the flow engine runs for parameter estimation (solver position 18)
• Monte Carlo stochastic: whatever flow engine is appropriate runs once per realization (solver position 19 specifies the count)

20.1.3 Where engine information is recorded

For users who want to see which engine is active in a specific model:

• Solver Options dialog — the main user-facing location; shows the current solver configuration including the active MODFLOW variant
• Simulation reports — post-simulation reports name the engines that ran
• Model file — parser-level: solver position 20 (MFsolverStr) stores the MODFLOW solver configuration, parseable as JSON; the "version" key indicates the engine (e.g., "mf6")
• Exports — exported MODFLOW files inherently specify their version through the file formats themselves (MF6 uses different block-structured input than MF2005)

20.2 The Native IGW Solver

For standard structured-grid groundwater flow problems, the native IGW solver is the default engine. Understanding what it is (and isn't) clarifies IGW-NET's multi-engine architecture.

20.2.1 What the native solver handles

The native IGW solver is a finite-difference groundwater flow solver specialized for:

• Structured rectangular grids — uniform cell geometry where all cells are the same size and shape (possibly multi-layer)
• Standard flow physics — steady-state or transient; confined or unconfined; with recharge, wells, drains, rivers, general head boundaries, etc.
• Tight integration with IGW-NET's real-time framework — the native solver is designed to produce results in the rapid, iterative interaction style that defines IGW-NET's user experience
• Integration with IGW-NET's internal features — T-PROGS K fields (Ch. 17), SGS random fields (Ch. 19), coupled lakes (Ch. 15), the Watershed Solver (Ch. 16) all work with the native solver

20.2.2 What the native solver doesn't handle

The native solver's design choices mean it doesn't handle:

• Unstructured grids — for refined-grid nested models (Ch. 13), the native solver cannot proceed; MODFLOW 6 DISV is required and is activated automatically
• Variable-density flow — SEAWAT handles this specifically; the native solver assumes constant density
• Some specialized formulations — Newton-Raphson handling of wetting-drying cells (MODFLOW-NWT's domain); certain advanced package behaviors not in the standard flow formulation

When a model requires any of these capabilities, IGW-NET switches to the appropriate MODFLOW engine automatically. The transition is transparent to the user — model setup and visualization look the same regardless of which engine is running underneath.

20.2.3 Why a native solver at all

Given that MODFLOW engines exist, why does IGW-NET have a native solver? Several reasons:

• Real-time responsiveness. The native solver is designed around IGW-NET's interactive interface — fast forward simulations, incremental updates as users modify the model, the real-time iteration pattern. MODFLOW engines, while excellent for batch simulation, are optimized for different use patterns.
• Integration with IGW-NET internals. Features like the Watershed Solver (Ch. 16), coupled-lake modeling (Ch. 15), and IGW-NET's internal analysis tools integrate natively with the native solver. MODFLOW-engine integration requires additional coordination that's handled automatically but can add startup overhead.
• Stochastic efficiency. The compute-render-discard architecture for Monte Carlo (Ch. 19 §19.6) relies on tight per-realization integration that the native solver supports efficiently.
• Simplicity for standard problems. For the majority of groundwater-modeling work — structured grids, standard flow — the native solver does what's needed without the overhead of external engine invocation.

For users, the practical takeaway: the native solver is invisible. Model setup and analysis look the same whether the native IGW solver or MODFLOW 6 is running underneath. The engine choice is an implementation detail handled automatically.

20.3 MODFLOW Engines — When Each Is Used

When MODFLOW engines do run, IGW-NET picks the appropriate version based on the model's requirements. This section clarifies which MODFLOW version goes with which kind of problem.

20.3.1 MODFLOW 6 — the modern default

MODFLOW 6 is USGS's current-generation groundwater flow engine and the default MODFLOW-variant for new work in IGW-NET:

• Unified flow and transport — single code base handles both
• DIS, DISV, DISU discretizations — structured, vertex-based unstructured, and general unstructured grids
• Block-structured input — a cleaner file format than legacy MODFLOW
• Modern package organization — NPF (Node Property Flow) for K and anisotropy; STO for storage; IC for initial conditions; etc.
• Active maintenance — USGS continues to develop MF6 with regular releases

In IGW-NET, MODFLOW 6 activates automatically for any model with unstructured grid refinement. The DISV discretization is the key — it's what allows the refined nested-model pattern from Ch. 13 to work. For users, the important detail: MF6 under the hood, IGW-NET interface on top.

20.3.2 MODFLOW 2005 — the widely-used legacy

MODFLOW 2005 was USGS's primary flow engine for many years before MODFLOW 6. It remains widely used because:

• Regulatory familiarity — many regulatory bodies have extensive experience reviewing MF2005 models; some workflows assume MF2005 specifically
• Ecosystem tools — many third-party tools (especially older ones) integrate with MF2005 more naturally than with MF6
• Documented reference cases — the published MF2005 literature is extensive

IGW-NET supports MF2005 for workflows that specifically require it. For new models without legacy constraints, MF6 is preferred.

20.3.3 MODFLOW-NWT — for difficult unconfined problems

MODFLOW-NWT is a variant of MODFLOW 2005 that uses Newton-Raphson iteration instead of the standard Picard iteration. The practical advantage:

• Better handling of wetting-drying cells — in unconfined aquifers where cells transition from saturated to dry or vice versa, classical MODFLOW can have convergence difficulties; NWT handles these transitions more robustly
• Appropriate for strongly unconfined problems — shallow water-table aquifers, water-supply wells near aquifer tops, wetland-aquifer interactions with dynamic saturation

When you have an unconfined model that won't converge cleanly with standard solvers, switching to NWT is often the fix.

20.3.4 MODFLOW-USG — legacy unstructured

MODFLOW-USG was USGS's first unstructured-grid MODFLOW variant. MODFLOW 6's DISV is generally considered its modern successor for the refined-grid use case. IGW-NET supports USG for workflows that specifically require it; for new work, MF6 is preferred.

20.3.5 Seeing and overriding the choice

You can inspect and, if needed, override the engine choice:

• Solver Options dialog — shows the active flow engine; also configures solver tolerances, iteration limits, and related parameters
• Automatic override cases — some features force specific engines (unstructured grids force MF6; variable density forces SEAWAT; these are not overridable)
• User-selectable cases — within structured grids, you can choose between native IGW, MF2005, or NWT for specific reasons (legacy compatibility, convergence issues)

The default is to let IGW-NET pick. Override only when you have a specific reason.

20.4 Feature-to-Package Mapping

For users who export to MODFLOW or want to understand how IGW-NET features correspond to MODFLOW's world, this section documents the main mappings.

20.4.1 The core mapping

This is the workhorse mapping — most IGW-NET groundwater-flow features have direct MODFLOW package equivalents. Exporting to MODFLOW produces a standard package-based file set that any MODFLOW user can read and run.

20.4.2 Transport packages (when active)

When solute transport is active (Ch. 12), MT3DMS handles the transport solve and adds its own package structure:

• BTN (Basic Transport) — core transport setup, stress periods, solver choice
• ADV — advection method (TVD, MOC, etc.)
• DSP — dispersion coefficients and dispersivity
• SSM (Source-Sink Mixing) — source concentrations at wells, boundaries
• RCT — reactive transport (when enabled)

MT3DMS reads the MODFLOW flow solution and produces the concentration solution on top. The two engines work together for coupled flow-and-transport.

20.4.3 Density-flow packages (SEAWAT)

For variable-density problems (solver position 17), SEAWAT combines MODFLOW flow and MT3DMS transport with density coupling:

• VDF (Variable Density Flow) — couples salinity to the flow equation
• Standard MODFLOW + MT3DMS packages — unchanged except for VDF coupling

Most coastal-interface and brine modeling uses SEAWAT; activating density flow in IGW-NET triggers the SEAWAT engine.

20.5 What Doesn't Transfer to Standard MODFLOW

Most IGW-NET features map to MODFLOW packages. Some don't, and understanding which is important when export is planned.

20.5.1 The Watershed Solver

The Watershed Solver (Ch. 16) is the most significant IGW-NET feature without a direct standard-MODFLOW equivalent. It computes overland flow, infiltration, and runoff as part of the integrated solve, producing a transient recharge field that the groundwater solver then uses. Standard MODFLOW expects recharge as an input (via the RCH package), not as a coupled output of a watershed subsystem.

On export:

• The recharge field at the time of export is written to RCH as a static or time-varying array
• The Watershed Solver dynamics are lost — external MODFLOW runs will use the exported recharge as fixed input, not as a computed response to climate and land use
• For watershed-coupled workflows outside IGW-NET, the typical alternative is coupling MODFLOW with SWAT (Ch. 16 §16.6) or running SwaNET separately to produce recharge inputs

If the Watershed Solver dynamics are essential to the problem, keeping work in IGW-NET is the better choice.

20.5.2 Interactive and real-time features

IGW-NET's interactive interface is not a file-level feature:

• Real-time visualization — on-the-fly rendering of heads, vectors, particles, cross-sections — is an IGW-NET interface feature
• Real-time analysis — water budgets, particle tracks, probability distributions at monitoring wells computed and displayed as the simulation runs
• Ensemble visualization — the compute-render-discard architecture (Ch. 19 §19.6) for stochastic modeling
• Data Center integration — spatial data that feeds into the model in real time

Export produces standard MODFLOW input/output files that any MODFLOW post-processor can read. External tools (ModelMuse, Groundwater Vistas, FloPy, custom Python scripts) can produce static visualizations from those files, but the interactive experience is IGW-NET-specific.

20.5.3 Integrated workflows

Some IGW-NET workflows combine multiple features in ways that don't translate package-by-package:

• The Automatic Calibration loop — UCODE parameter estimation with IGW-NET's interactive chart (Ch. 18) — you can export the final calibrated model, but the interactive calibration process itself doesn't export
• Multi-target calibration integration — IGW-NET handles simultaneous fitting of SWLs and lake stages; external MODFLOW workflows would require separate configuration of UCODE with multi-target observations
• Sub-time-step coupling for coupled lakes (Ch. 15 §15.2.4) — exported to LAK, the lake-aquifer coupling is represented but the interactive exploration of the coupling is not

For any of these, exporting captures the end state; the interactive development process is IGW-NET-specific.

20.6 Export Workflow

When export to standard MODFLOW is the goal, here is how the workflow proceeds in IGW-NET.

20.6.1 What you get

An export produces a complete MODFLOW input file set:

• Name file — lists all packages used
• Package files — DIS/DISV, NPF, WEL, DRN, RIV, LAK, RCH, STO, IC, OC, etc., populated from the IGW-NET model's configuration
• Array files — the K field (including T-PROGS or SGS heterogeneity), recharge field, initial heads, etc. — written as MODFLOW-readable arrays
• Transport inputs — if transport is active: BTN, ADV, DSP, SSM, etc.
• Solver configuration — IMS (MF6) or solver packages (MF2005) with the tolerances and iteration settings

The result is a self-contained MODFLOW model that runs in external MODFLOW without IGW-NET. Results (heads, fluxes, budgets, transport concentrations) match what IGW-NET produces for the same configuration.

20.6.2 Export triggers

Export is typically invoked through:

• File menu export option — explicit export to MODFLOW file set
• Some specialized workflows — certain analyses may automatically produce intermediate MODFLOW files

The exported version corresponds to the MODFLOW engine IGW-NET selected for the simulation. A MODFLOW-6-solved model exports MF6; a MODFLOW-2005-solved model exports MF2005. Unstructured models (MF6 DISV) export in MF6 block-structured format.

20.6.3 Running the exported model

Once exported, the file set runs in any standard MODFLOW environment:

• Command-line MODFLOW executables — USGS-distributed binaries for each engine version
• MODFLOW-ecosystem tools — Groundwater Vistas, GMS, ModelMuse, FloPy (Python), etc. — read the standard MODFLOW file formats
• Regulatory-submission workflows — where reviewers use their own MODFLOW setup to verify or inspect

Reproducibility: the same model file set produces the same numerical solution regardless of which MODFLOW execution environment runs it. This is part of what makes MODFLOW file exports credible for regulatory and review contexts.

20.7 When to Export vs. Stay in IGW-NET

Export is a specific tool for specific needs, not a default step. For most work, IGW-NET's integrated environment is the more productive place.

20.7.1 When to export

• Regulatory submission — jurisdictions that require raw MODFLOW input files for review. Common in several US states and some international contexts.
• External validation — when reviewers want to inspect the model at the MODFLOW-file level, possibly using their own MODFLOW tools.
• Project handoff — transferring the model to a team that works exclusively in MODFLOW-ecosystem tools (FloPy-based pipelines, GMS, Groundwater Vistas, custom Python frameworks).
• Specialized external tools — integration with MODFLOW-ecosystem tools that aren't natively available in IGW-NET.
• Archival — storing the model in a portable, engine-specific format that will remain readable independent of IGW-NET platform evolution.
• Teaching — students learning MODFLOW file structure can use IGW-NET-generated exports as reference examples.

20.7.2 When to stay in IGW-NET

• Active modeling work — the interactive interface, real-time visualization, Data Center integration, and rapid iteration are productivity features that don't transfer. Don't export in the middle of modeling.
• Coupled-lake work (Ch. 15) — LAK package export works, but interactive exploration of lake-aquifer coupling is lost
• Watershed-coupled work (Ch. 16) — the Watershed Solver doesn't transfer; keep work in IGW-NET if this coupling is active
• Stochastic analysis (Ch. 19) — each realization could theoretically export, but the ensemble statistics and visualization are IGW-NET-specific
• Automatic Calibration (Ch. 18) — the integrated Calib checkbox + UCODE loop works best inside IGW-NET
• Collaborative workflows (Ch. 29) — the Observatory-integrated collaboration features are IGW-NET-specific

20.7.3 Mixed workflows

A common productive pattern: do the interactive modeling work in IGW-NET; export only at handoff or submission points.

This captures the best of both worlds: IGW-NET's integrated environment for building, analyzing, calibrating, and exploring the model; standard MODFLOW files as the portable output when needed for specific external purposes. Not a choice between platforms; a sequence of appropriate tools at appropriate times.