Metaissue: Ribasim-Modflow6 coupling

[Hofer-Julian]

• Install ribasim_api locally from git (both)
• Add ribasim_api git dependency to imod_coupler (Julian)
• Add ribasim to pytest fixtures (Julian)
• Add driver ribamod (Julian)
• Create minimal, tailor-made MODFLOW6 and Ribasim model (Huite)
• Couple MODFLOW6 and Ribasim (Huite)
• Document coupling: Document coupling with iMOD Coupler #385
• Add interpolation for the volume to waterlevel table: Add interpolation for the volume to waterlevel table #284
• Create coupling tables with iMOD Python: Create coupling tables with iMOD Python #285
• Allow exchange of multiple heads per basin (for multiple river/drainage systems): Allow coupling of multiple river/drainage cells per basin #514
• Couple DFM nodes to MODFLOW boundaries Coupling preprocessing: Ribasim H-h relationship to H-h-h #631
• Make debugging of Ribasim easier: Make debugging of ribasim_api easier #286
• Release ribasim_api: Release ribasim_api #287

[gijsber]

As discussed during meeting WS AA&MAAS (Joachim, Frank), WSL (Jurriaan), Deltares (Huite, Hendrik, Timo), WEnR (Ab), 22/9/2023
Topic: how to connect secundary and tertiary system and derived associated coupling data in hilly terrain

Assumption: a D-Hydro model is available for the primary system
D-Hydro provides QH-relations for the primary system as well the relation to translate the H or V from Ribasim to local h in the modflow river cells as covered by the primary system/D-Hydro model.

Proposal: use (at least) two Ribasim basins, one for the primary system, one for the secundary system
Conduct a DEM drainage analysis, supported with drainage areas afwaterings gebieden) or culvert information, to derive a routing of the secundairy system.
This network routing determines where the secondary system connects to the primary system.
At this connection point the head of the primary system is assumed similar to the head of the secondary system.
For the upstream branch of the secundary system one assumes a horizontal water level (i.e. same h).
In this way, the h-H relation can be derived

The volume relation for the secundary system can be derived from the DEM

To connect the basin representing the secundary system to the basin representing the primary system a QH-relation is derived using general characteristics of the secundairy system such as avg.profile, average length till the connection, representative Manning coefficient etc.

[Huite]

Implementing this succesfully requires mostly preprocessing logic, and a limited set of functionality for Ribasim and the imod-coupler. Most of the work is likely included in the preprocessing.

There are as of yet no additional requirements in terms of the levels that Ribasim computes. We foresaw a unique basin_level -> modflow_level relationship for every active boundary condition (#284).

In overview, the general requirements for a coupled model are:

• An existing D-Hydro model (with a dozen or so stationary water levels):

  • We need to integrate the total volume for a given basin.
  • We need to the water level at the representative location, and for each MODFLOW cell.

• An existing MODFLOW 6 model. Additionally consistent data:

  • A hydrological routing for each cell for each class. These routings may be available in some cases, but will likely have to be generated, especially since they depend on cellsize.
  • These are required to link up each boundary with the appropriate D-HYDRO water level.
  • The water level distribution is the secondary basin is estimated by propagating the D-HYDRO water level via reverse routing.
  • Cross section profile for each cell for each class. These will generally consist of overview tables with typical characteristics for the water body class. This is combined with the water level to yield a volume (which may then integrate).

• As Ribasim input: for each class of water body, characteristics to estimate Q-h relationships (e.g. secondary to primary) or resistances.

The list below is an attempt to break down the preprocessing requirements:

• Coupling pre-processing: find relationship between (representative) basin-level and MODFLOW boundary  #620
• Coupling pre-processing: allow spatially overlapping basin definition #616
• Coupling pre-processing: (DEM-based) routing #617
• Coupling pre-processing: Link any cell to an available appropriate water level #618
• Coupling pre-processing: compute volumes for each MODFLOW boundary #619

However, the first step is to test a much simpler case where we only "actively" manipulate the water levels of the reaches that are explicitly modeled by D-HYDRO. All other MODFLOW boundaries are simply coupled in a passive manner (where they discharge, cannot infiltrate, and their water levels are not changed by the coupler). Conceptually, this is quite comparable to the function of the "laterals" in the hydraulic model, whereas each additional steps actually demands a more detailed description than either D-HYDRO or MODFLOW currently use (!).

In terms of pre-processing, it requires only the result of #620.

[Huite]

I suggest resolving the following three issues:

• Ribamod: priority of forcing and uncoupled basins #998
• Ribamod: support uncoupled MODFLOW boundaries and Ribasim basins #999

Then closing this meta-issue.

There will assuredly be many additional improvements (especially in terms of preprocessing robustness and the like), but they can be easily picked up piece by piece now.