Add interpolation for the volume to waterlevel table

[Hofer-Julian]

We need interpolation for the volume to waterlevel table.
We also need to decide where to put this functionality.

• If we put it in iMOD Python the input files would become bigger,
• if we put it in Ribasim, Ribasim would become geometry-aware.

[Huite]

After discussing this with Julian, we've come to some conclusions.

Ribasim can run in multiple configurations (e.g. strongly lumped or not), and that means the water level that is communicated to MODFLOW 6 can be computed in multiple ways. For example:

• 3.5 "basins" in a single MODFLOW river cell, for a single MODFLOW River boundary
• 1 basins for dozens of MODFLOW river cells, for a single MODFLOW River boundary
• 1 basins for dozens of MODFLOW river cells, for multiple MODFLOW River boundaries

And so forth, also for MODFLOW Drainage boundaries, since they are used to simulate a difference between infiltration and drainage conductance.

One solution is to associate weights with the connection, since imod_coupler supports this via sparse matrix operations. The limitation is that the imod_coupler weights are static, which may prove insufficient in the future (e.g. flooding or drying in Ribasim).

The most attractive solution so far seems to let Ribasim present a 1:1 water level for MODFLOW 6. This means that Ribasim will require additional input, describing how to create a spatially distributed water level for basins. Such input ideally be spatially meaningful to help with input inspection and debugging. This is also useful separate from the coupling, since a spatially distributed water level is very useful for interpretation.

However, to get spatially meaning input, we require spatial formats. Given the type of data, something like (UGRID) netCDFs seem like the most obvious choice. At any rate, QGIS should be able to visualize it.

This also means that the imod_coupler logic can remain absolutely minimal: it takes the water levels as computed by Ribasim, and puts them in the MODFLOW 6 memory. Then the only thing to configure for the coupling is which MODFLOW boundary conditions should be coupled.

[Huite]

Consider:

Six MODFLOW cells (with associated river boundary conditions), and four Ribasim basins. For MODFLOW cell 1-2-3, we have to take one water level and expand it into three stages for MODFLOW. For cell 4, we have to aggregate instead.

For the upper cells, we'd want to interpolate based on some input, to enable different river bottom levels for example. This isn't the case for cell 4. In such a case, the water level should be interpreted directly, and no interpolation logic is required. I think that argues for separating the logic into different types, and also separating the input.

The coupling for cell 4 requires aggregation weights. I think it makes most sense to scale them directly by the wetted area of each basin. This is also a good reason to disallow having "3.5" basins in a single cell, since we need an additional set of weight to adjust the area weights.

For the aggregated (ribasim: modflow = one: many) case, we'd need the columns:

• basin_id
• basin_level
• modflow_id (this is the ID of the boundary condition, not the cell number! Node number in MODFLOW may change to re-ordering or inactive cells)
• modflow_level

("modflow" is a stand-in here, it could be anything, since this functionality can also be used to compute back to the DFM levels.)

For the distributed (ribasim:modflow = many: one) case, we'd need only:

• basin_id
• modflow_id

[Huite]

Sub-issues so far:

• Add "export_subgrid_levels" to config #679
• Add an SubgridLevelExporter Callback #680
• Add validation for SubgridLevel interpolation #681

[Huite]

Fixed by #674