Proposal: Dedicated Boundary Condition for Simulating Draining Subsurface Structures (Tunnels)

[d-strom]

Hi everyone,

For many years I have struggled with how to best represent tunnels in MODFLOW in a physically consistent and reproducible way. The common approaches — DRN, CFP, CLN, and sometimes MAW — all have significant limitations, and none of them provide a fully satisfactory conceptual or practical solution for this type of problem.

In practice, tunnel drainage is most often approximated using drain boundaries, but this quickly becomes highly empirical. The conductance term must somehow represent a complex combination of:
• tunnel geometry,
• hydraulic connection between rock and tunnel,
• grouting and lining properties,
• skin effects and excavation disturbance,
• scale effects relative to grid resolution.

Despite reading several technical reports and guidelines, I have not found a generally accepted, physically based and reproducible method for defining drain conductance for tunnels. As a result, conductance often becomes a calibration parameter, which undermines predictive modeling. This is particularly problematic since tunnel simulations are typically performed before construction, when flow observations are unavailable and predictive capability is the primary goal.

This leads me to a more fundamental question:

Would it be feasible and useful to introduce a dedicated boundary condition in MODFLOW specifically designed to represent draining subsurface structures such as tunnels?

Such a boundary condition could be parameterized more directly using physically meaningful properties, for example:
• tunnel cross-sectional dimensions,
• tunnel length within each cell,
• lining and grout thickness,
• hydraulic conductivity of lining and grout,
• optional skin factor or excavation damage zone,
• possibly anisotropic or directional flow effects.

Conceptually, this boundary would represent a line or sub-grid scale sink with a converging flow field, instead of approximating the tunnel as a planar drain surface.

In theory, similar behavior can be approximated using DRN, but the lack of a clear and reproducible method for deriving conductance makes this approach unreliable for prediction. While calibration against measured tunnel inflows is possible, it defeats the purpose in cases where the tunnel does not yet exist.

Given how common tunnel and underground construction projects are in hydrogeological modeling (transport tunnels, hydropower tunnels, deep repositories, mining, etc.), it seems that a more physically based and standardized representation could be highly valuable for the community.

I would be very interested in hearing thoughts from the developers and other users:
• Has this been discussed before?
• Are there conceptual or numerical reasons why such a BC would be difficult to implement?
• Could this perhaps be implemented as a package extension or external coupling?

Looking forward to your thoughts and discussion.

Best regards,
David

[mjr-deltares]

Hi David,

Thanks for posting to the discussion board. Personally I have not heard this being discussed before, but maybe others can pitch in here.

It seems to me that am external package extension could be a good candidate to prototype this kind of functionality and share it with the community. We have successfully used the MODFLOW API for similar issues in the past, so it could be worth the investigation. What I am thinking of is the use of the API package to insert a placeholder package inside the MODFLOW GWF model that will allow you to insert coefficients into the balance equation (hcof(i) and rhs(i) for cells i part of the boundary) through the API. You could run the simulation from a Python script or notebook and provide a formulation to calculate the tunnel coefficients and insert them timely into the system. An advantage is that a couple of things are automatically taken care of by MODFLOW, such as the recording of the budgets or a possible link with the Mover package to transfer water from the tunnel somewhere else. Another advantage is that you yourself fully control the details of how the coefficients are calculated so you can choose an optimal formulation. Though documentation on the MODFLOW API is possibly a bit limited, I believe there are sufficient examples around to assist with setting this up.