Nested Modeling — Regional Context, Local Detail

13.1 Why Nest — The xyz/ijk Argument

Nested modeling is not just a convenience — it is the direct consequence of the conceptual-versus-numerical distinction introduced in Chapter 1 §1.5.1. This section lays out the reasoning explicitly, because understanding why you nest makes the when and how clearer.

13.1.1 The core problem — single-grid inadequacy

Real aquifer systems span scales: a regional flow pattern driven by climate, topography, and regional geology; a local flow pattern affected by specific wells, streams, and small-scale heterogeneity. A single numerical grid (ijk) has one resolution — every cell in the domain is the same size. If you set that resolution coarse enough to keep the regional model computationally tractable, the local features are under-resolved. If you set it fine enough to resolve local features, the regional computation is wasteful (most of the fine cells are in areas where coarse cells would suffice).

This is a fundamental tension between ijk and xyz. The conceptual reality (xyz) naturally has multi-scale structure. A single-resolution numerical representation (ijk) cannot honor both regional and local scales simultaneously. Nested modeling resolves the tension by using multiple ijk representations — a coarse one for regional context, a fine one for local detail — linked through boundary-condition inheritance.

13.1.2 The compute-cost argument

Grid cost scales roughly with the square (2D) or cube (3D) of resolution. Doubling NX from 40 to 80 quadruples the 2D cell count; doubling sublayers from 1 to 2 and NX from 40 to 80 octuples the 3D cell count. Most serious simulations scale superlinearly with cell count because the solver iterations multiply. The practical effect: uniformly refining a large domain to get local detail is expensive, often prohibitively so.

The nested approach delivers arbitrary local resolution for a cost that's only a small multiple of the parent-alone cost. This is the efficiency that makes very-fine local simulations practical in IGW-NET even on a web-based platform.

13.1.3 When a submodel is worth creating

You want a submodel when:

• A local feature needs finer resolution than the parent's grid provides. A pumping well, a specific source zone, a detailed stream network, a plume area. The parent resolves the regional flow well enough; you need to zoom in on the local structure.
• You're doing site-specific transport in a regional flow context. Standard for any contamination investigation with regional implications — the local source and plume need fine-grid transport while the regional groundwater divides and streams remain in the parent.
• You want WHPAs or GDE recharge areas with defensible resolution. A WHPA delineation demands sharper cell resolution near the well than a regional parent can economically provide (Ch. 11 §11.5.2).
• Your calibration is local, but your physics is regional. You have monitoring data at a site; you need flow calibrated locally. A submodel gets the regional drivers right automatically (via BCs) while you tune local K and layer detail.
• You need to compare scenarios at a site. Running alternative local configurations is cheap because the parent solution can be reused; each submodel variant is a short simulation against the same parent flow field.

13.2 The Submodel Workflow — Two Approaches

IGW-NET offers two distinct ways to create a submodel: the zone-based approach (ZoneRect + Submodel Domain checkbox) and the domain-based approach (DrawDomain inside the parent area). Both link to the parent through the Boundary Condition from Parent Model flag, and both produce the same submodel simulation. They differ in workflow convenience and in what they let you do afterward. This section walks through each approach and explains when to use which.

13.2.1 Prerequisite — a converged parent model

Before creating any submodel, you need a converged parent — your regional model with domain drawn, attributes configured, features defined, and a successful SIMULATE. Check the water balance (Ch. 8), confirm head contours look physically reasonable, and confirm there are no error messages. The submodel's BCs come from the parent's computed heads, so if the parent is poorly calibrated or badly gridded where the submodel will be, those errors propagate into the child. Spend the time on parent calibration first.

13.2.2 Approach A — The zone-based workflow (recommended)

The zone-based approach is IGW-NET's preferred workflow for submodels. You draw a zone in the parent model, flag it as a Submodel Domain, and the platform treats that zone as the active simulation domain when BC-from-parent is enabled. Here is the full procedure:

Draw a zone with ZoneRect or ZonePoly

Click Conceptual Model Tools → Zones → ZoneRect (or ZonePoly if you want an irregular submodel boundary). Click corners on the map to define the zone's geometry. Apply the 10-cell buffer rule above when sizing.

SaveShape and check Submodel Domain in Zone Attributes

Click SaveShape. The Zone Attributes dialog opens. In the default "Flow Property" tab, find the Zone Types subsection and check the Submodel Domain box. Click Save.

Enable BC from Parent Model in Simulation Settings

Click Conceptual Model → Domain Attributes → Simulation Settings, and check Boundary Condition from Parent Model. Click Save.

SIMULATE

Click SIMULATE. The platform steps through three confirmation prompts (accept each one); the submodel simulation begins at its finer resolution with parent heads as BCs.

13.2.3 Approach B — The domain-based workflow

The second approach uses DrawDomain to create a new, smaller domain inside the area the parent covered, then references the parent for BCs. The workflow:

1. With the parent model converged, click Conceptual Model Tools → DrawDomain and draw a new domain polygon in the area of critical interest (e.g., the remediation site). Apply the 10-cell rule when sizing. When you commit the new domain, the previous parent domain is erased — IGW-NET only ever holds one active domain at a time — but the parent's boundary-head values at the new domain's perimeter are captured into an internal exchange field before the erasure.
2. Attributes for the new domain are populated from the Global Base Model (not from the parent, which is gone).
3. In Simulation Settings, check Boundary Condition from Parent Model. This tells IGW-NET to read BCs from the saved exchange field rather than defaulting to no-flow.
4. SIMULATE. The new, smaller domain runs with fixed-head BCs sourced from the exchange field.

13.2.4 Choosing between the two approaches

For most practical work — and especially for any investigation involving hierarchical nesting or comparison between candidate submodel locations — the zone-based approach is strongly preferred. The domain-based approach has its place but erases what came before.

13.2.5 The visual check — reading the submodel solution

13.2.6 Switching back to the parent

With the zone-based approach: uncheck Boundary Condition from Parent Model in Simulation Settings (or uncheck Submodel Domain on the zone), then SIMULATE. The platform returns to parent mode and uses the full parent domain. You can toggle freely — each has its own grid and its own simulation.

With the domain-based approach: you need to load the parent's saved model file, since the current domain has been replaced.

13.3 What Inherits, What Doesn't

Understanding exactly what the submodel gets from the parent — and what you still need to specify yourself — is essential to using submodels correctly. The rule of thumb: boundary conditions inherit automatically; interior representation is yours to refine.

13.3.1 What inherits automatically

13.3.2 What does NOT inherit automatically

The submodel is an opportunity to refine the representation, not just copy it. So interior features are yours to define — potentially differently from how they appeared in the parent:

13.3.3 Keeping parent and submodel in sync

Changes to the parent (e.g., a new well added regionally, a changed recharge rate, a re-calibrated K field) can affect the submodel's BCs. When you change the parent, re-SIMULATE the parent to update its flow solution, then re-SIMULATE the submodel so it picks up the new BC values. The platform does not automatically propagate parent changes into submodel results — the submodel's BCs are from the parent's last-solved state.

This usually isn't a problem during active model development (you're iterating on one level at a time), but it's worth knowing. A stale submodel solution that shows "wrong" heads at its boundaries is often just a submodel that hasn't been re-simulated since the parent was updated.

13.4 Placing the Submodel Boundary

Where you draw the submodel's outer rectangle matters. The parent's computed heads along that rectangle become the submodel's boundary conditions — so if the parent's heads are unreliable there, the submodel inherits the unreliability.

13.4.1 Rules of thumb

13.4.2 Exception — when an edge coincides with a natural boundary

A useful exception to the "away from edges" rule: if a natural hydrologic boundary (a major river, a lake, a groundwater divide) coincides with a parent edge, a submodel boundary there is fine — even helpful. The parent's head at the river is controlled by the river itself (through surface-water coupling), so parent-heads there are physically meaningful and defensible. The submodel inherits a physically-grounded BC rather than an artifact. Example: a parent whose western edge is a major lake can host a submodel whose western edge is the same lake without penalty.

13.4.3 Iterating to find a good boundary location

13.5 Hierarchies — Submodels Inside Submodels

A submodel can itself host a submodel. This nesting can continue to arbitrary depth in principle, though three to four levels is the practical maximum in most applications. Hierarchical nesting is how IGW-NET handles genuine multi-scale problems where the xyz reality has structure spanning many orders of magnitude. But the case for hierarchy is stronger than "it handles multi-scale problems" — hierarchy is the right organizing principle for modeling, assimilation, visualization, and data transmission simultaneously. This section starts with the deeper argument, then works through the operational specifics.

13.5.1 Why hierarchical modeling is fundamental, not just efficient

Nested modeling is often framed as a numerical trick — a way to avoid building an enormous single grid. That framing undersells it. Hierarchical organization is fundamentally the right way to represent and work with multi-scale information, for reasons that go far beyond compute cost. Four arguments, each independent, each pointing the same direction:

Numerical — many small models solve more robustly than one big one

A single monolithic model covering multiple scales at uniform fine resolution is numerically harder than the sum of its nested equivalents. Large grids produce large, ill-conditioned linear systems; convergence slows non-linearly with problem size; coupled failure modes (one region's problem cascading into the whole solution) become more common. A three-level hierarchy of small, well-posed problems is more robust at every level: each individual solve converges faster, each is independently diagnosable, each can be re-simulated in seconds rather than minutes. If the plume-area sub-submodel has a convergence issue, it's isolated — the regional and watershed solutions stay clean. In a monolithic model, the same issue could contaminate the whole field, and diagnosis requires picking through a million-cell solution to find where things went wrong.

Cognitive — humans assimilate hierarchically, not pixel-by-pixel

Even if the machine can solve a monolithic model perfectly, a human user cannot assimilate the result as a flat field of values. Comprehension is hierarchical: first the overall pattern (regional flow direction, major discharge areas), then the intermediate structure (watershed-scale features, local flow convergence), then the details (plume shape, individual well capture). Looking at a million head values at uniform resolution overwhelms the eye and the mind. A hierarchy of views — regional at coarse resolution, site at moderate resolution, plume area at fine resolution — matches how humans build understanding. Each level presents about as much information as comprehension can absorb at that scale; the finer levels carry the detail that would have been noise at coarser levels and clutter at monolithic resolution.

Management — decisions are made hierarchically

Different stakeholders in a real groundwater study need different views. A regulator wants to know whether the aquifer system is protected — regional-scale answer. A site manager wants to know whether this site's remediation is on track — site-scale answer. A plume-response engineer wants to know whether the extraction well is capturing the plume — plume-scale answer. These are the same physical system, examined at different levels of detail. A single monolithic model tries to answer all three at once and ends up being unwieldy for each. Hierarchical models match the decision structure: the right level of detail reaches the right decision-maker without requiring everyone to work with full-resolution data. This is how organizations have always structured technical information — executive summary, technical report, detailed appendix — and modeling deliverables work the same way.

Infrastructure — hierarchy matches how data transmits across the internet

Modern groundwater work is browser-based, collaborative, and distributed. Transmitting a million-cell uniform model over the internet, to a browser, for a user to interact with, is impractical — the bandwidth cost is real, the render cost is real, and the interaction latency kills productivity. Hierarchical models transmit only what the current view needs: a coarse regional field when looking at regional scale, finer fields when you zoom in, full detail only for the sub-area currently in focus. This matches how web-based mapping has always worked (Google Maps doesn't send you all the world's tiles at every zoom level) and how cloud-native scientific computing increasingly works. IGW-NET's streaming-visualization architecture assumes hierarchy — it is how the platform achieves the responsive, interactive feel it does. A non-hierarchical representation would not fit the delivery medium.

13.5.2 Why the 10-cell rule often forces a hierarchy

Beyond the four fundamental arguments in §13.5.1, there is a specific technical reason the hierarchy is often required rather than just preferred: the 10-cell-buffer rule from §13.4 cannot be satisfied in a single submodel level when scale disparity is severe. Consider what happens with a 1000× scale disparity — a 100 km × 100 km regional parent and a 100 m × 100 m area of critical interest:

• If you try to jump directly from the regional parent to a submodel tight around the 100 m area, the submodel must be much larger than 100 m — the 10-cell rule says the area of interest needs ~10 submodel-cells of buffer on each side. At NX = 40 covering 1 km (100 m cells), that 10-cell buffer only gives you a few hundred meters of breathing room. That's still acceptable — but the submodel is now a 1 km × 1 km domain that is being reached directly from a 100 km × 100 km parent, a 100× jump in scale.
• That 100× scale jump is at the edge of what parent BCs can reliably support. Parent cells at NX = 40 over 100 km have 2.5 km cell size; BCs interpolated from 2.5 km cells to a 100 m submodel edge are being stretched across 25× resolution mismatch. Contour discontinuities, head interpolation errors, and BC artifacts can become noticeable.
• The solution is an intermediate level: put a 10 km × 10 km watershed submodel between the regional parent and the plume-area sub-submodel. Now the regional-to-watershed jump is 10× (manageable), and the watershed-to-plume jump is another 10× (also manageable). The 10-cell rule is satisfied at each level because each level only needs to buffer against the next-coarser level's cell size, not against the regional parent's.

In short: huge scale disparity forces a hierarchy, because a single submodel level cannot simultaneously satisfy the 10-cell buffer rule and avoid stretching parent BCs across too large a resolution mismatch. The hierarchical workflow is the natural answer — and the zone-based approach in §13.2.2 (multiple submodel zones coexisting) is the platform feature that makes multi-level hierarchies practical to build and navigate.

13.5.3 The typical three-level hierarchy

Each level inherits its BCs from the next-coarser parent. The plume-area sub-submodel sees detailed local features (source, pumping wells, monitoring network) at high resolution, while its BCs are shaped by the site-scale watershed model, which in turn was shaped by the regional parent. Regional information flows down through the hierarchy to the most-detailed level without being lost in grid coarsening.

13.5.4 Why this works — the light-weight advantage

Each level of the hierarchy is a single, light simulation. The plume-area sub-submodel at NX = 160 with a 1 km × 1 km domain has 160 × 160 = 25,600 cells — large but not excessive. The watershed submodel at NX = 80 with a 10 km × 10 km domain has 6,400 cells. The regional parent at NX = 40 with a 100 km × 100 km domain has 1,600 cells. Each individual simulation is fast; together they cover five orders of magnitude in spatial scale with local resolution a thousand times finer than the regional.

Compare to a single unified grid covering the same 100 km × 100 km at 62.5 m resolution (matching the plume-area's NX = 160 on a 1 km subdomain): you'd need 1600 × 1600 = 2.56 million cells. That's 160× as many cells as the entire three-level hierarchy combined. The hierarchical approach is a fundamental efficiency, not a marginal optimization.

13.5.5 Practical workflow for a hierarchy

In principle the hierarchy can go deeper — sub-sub-sub-models — but beyond three levels the overhead of coordinating multiple nested BCs usually outweighs the benefit. Three levels is enough for the vast majority of real problems.

13.6 MODFLOW-6 Unstructured Refined Grid — The Alternative Approach

IGW-NET offers a second refinement mechanism besides nested submodels: unstructured refined grid, a MODFLOW-6 feature that refines cells locally within a single simulation rather than creating a separate child. This section covers when each approach fits.

13.6.1 What unstructured refined grid does

Standard structured grids have uniform cell size throughout the domain. Unstructured grids allow cell size to vary — cells near specific features (wells, polylines, or zones you flag for refinement) are finer, and cells far from those features are coarser. The entire grid is one simulation in the MODFLOW-6 DISV (Discretization by Vertices) engine; you don't switch between parent and child models.

In IGW-NET, you flag specific features for refinement by setting their "isRefined" property through the feature's attribute dialog. When MODFLOW-6 is the active solver, the platform builds an unstructured grid that refines locally around each flagged feature.

13.6.2 When to use refined grid versus nested submodels

The real decision rule is about scale disparity — how different are the scales you're trying to simultaneously resolve?

• Significant scale disparity (regional vs local, orders of magnitude different) — use nested submodels. A 100 km × 100 km regional context with a 1 km × 1 km area of interest is a 100× scale disparity; a 10 km × 10 km site with a 100 m × 100 m source zone is a 100× disparity. Each level of a nested hierarchy gets its own grid tuned to its own scale, and you can examine each scale independently.
• Same scale, larger domain, need better feature representation locally — use unstructured refined grid. When the domain is relatively large (say 10–20 km across) but you need finer numerical resolution around specific features — a few wells, a meandering stream reach, a specific zone boundary — DISV refines cells locally while keeping the rest of the domain at reasonable resolution. One simulation, one coherent grid, refinement where features live.

13.6.3 Setting up unstructured refined grid

13.7 Common Pitfalls

A short catalog of the most common nested-model issues and what to do about them.

13.7.1 Submodel boundary too close to parent edge

Symptom: Submodel solution looks strange near the boundary — anomalous heads, mass-balance errors, contours running parallel to the boundary in unphysical ways.

Cause: The parent's edge artifacts (from its own no-flow BCs) are propagating into the submodel via the inherited fixed-head BCs.

Fix: Either enlarge the submodel to move its boundary further from the parent's edge, or enlarge the parent domain so its edge is further from where the submodel will go. The parent should be at least one submodel-width larger than the submodel in every direction.

13.7.2 Forgot to enable Boundary Condition from Parent Model

Symptom: Submodel contours are orthogonal to the submodel's outer boundary — the characteristic visual signature of no-flow boundaries.

Cause: The Submodel Domain zone is checked, but the Simulation Settings flag is not. The submodel is simulating as a standalone model with default no-flow BCs, not inheriting parent heads.

Fix: Go to Domain Attributes → Simulation Settings, check Boundary Condition from Parent Model, save, re-SIMULATE.

13.7.3 Parent changed but submodel wasn't re-simulated

Symptom: Submodel results don't reflect recent parent changes (new wells, updated K, modified recharge).

Cause: The submodel's BCs are from the parent's last-solved state. Changing the parent's inputs doesn't automatically update submodel BCs — you need to re-simulate the parent first, then the submodel.

Fix: After any parent change, the workflow is: re-SIMULATE parent → switch to submodel mode → re-SIMULATE submodel.

13.7.4 Accidentally erased the parent by using DrawDomain

Symptom: The parent model is gone; only the smaller domain remains. Switching back to the regional view isn't available in the current session.

Cause: Used DrawDomain (Approach B) to create a smaller model instead of the Zone-based Submodel Domain workflow (Approach A). IGW-NET only holds one active domain at a time; DrawDomain replaces it. The parent's boundary-head values were captured into the exchange field before the erasure (which is how the new domain gets its BCs), but the parent's geometry, features, and attributes are no longer in the session.

Fix: Reload the parent model from its saved file (Ch. 2). For future work where you want to preserve the parent and switch between regional and local views, use the Zone-based approach (§13.2.2): multiple submodel zones can coexist in a single parent.

13.7.5 New submodel zone drawn but simulation uses the old one (silent failure)

Symptom: You drew a new Submodel Domain zone over a different area of interest, simulated, and the result shows the flow solution for an earlier submodel region — not the new one. Nothing errors out; the simulation completes; but the area you just drew appears to have had no effect.

Cause: Only one submodel zone can be active at a time. When you created the new zone without first unchecking the previous zone's Submodel Domain flag, the platform kept the previous zone as the active submodel and ignored the new one. This is a silent failure — IGW-NET does not warn you, and the solution that appears is still a valid submodel solution, just from the wrong zone.

Fix: Open the Zone Attributes dialog for the previous submodel zone and uncheck Submodel Domain. Confirm the new zone has Submodel Domain checked. Re-SIMULATE. As a diagnostic: before simulating a newly-drawn submodel zone, verify which zone is active by opening each submodel-candidate zone and confirming only the intended one has the flag checked.

13.7.6 Interior features missing from the submodel

Symptom: Wells, zones, or streams that should be in the submodel are absent from the simulation.

Cause: These features must be defined while in submodel mode to be active in the submodel simulation. Features defined in parent mode exist in the parent but may not be propagating into the submodel's active feature set.

Fix: In submodel mode, confirm each interior feature is present; re-add any missing features at submodel resolution.