We recently made some progress in coupling HydPy-W(ALRUS) and SOBEK 3 in a bidirectional manner, allowing us to simulate both effluent in influent flow conditions. The feedback and the possible reverse flow from surface water (SOBEK) to groundwater (HydPy-W) generally make simulations more realistic and help circumvent the "over drainage problem" we and others encountered in previous studies when applying HydPy-W or the original WALRUS model in a standard unidirectional coupling.

This approach (based on BMI) is excellent for detailed studies but requires detailed information on channel geometries for building a SOBEK 3 model and is computationally time-consuming. Hence, we next plan to support a more "lumped" approach via bidirectional coupling of HydPy-W with HydPy-Dam-Pump, HydPy-Dam-Pump-Sluice, and HydPy-Dam-Pump-Sluice.

HydPy-W and SOBEK 3 are coupled via individual Python scripts that equate each trench of the SOBEK model with the surface water storage of a separate HydPy-W instance. For connecting HydPy-W with HydPy-Dam, we strive for a computationally more efficient and general solution that does not require setting up problem-specific scripts, maybe something similar to using a HydPy-Exch-Weir-HBV96 instance for allowing bidirectional flows between two lakes modelled by separate HydPy-Dam-L-Lake instances.

An HydPy-Exch-Weir-HBV96-like approach would introduce some additional configuration burden on the users and introduce some inaccuracies into the results as feedback could only be accounted for with a time delay of on simulation step. Also, HydPy-Dam's water volume to water level relationship and HydPy-W's surface water storage geometry would need to be synchronised, or additional calculation inaccuracies could appear.

Another idea is to allow HydPy-W to use HydPy-Dam as a submodel. This might be the approach with the smallest amount of required stopgaps. However, it would be a very new kind of functionality and the first time we couple two models defined via ordinary differential equations via the submodel approach. Hence, it is hard to foresee the required amount of work.

Two alternative solutions that come into my mind but do not seem worth further contemplation are to implement specific models that combine the required HydPy-W and HydPy-Dam functionalities (very ugly) or somehow insert user-made functions that do the coupling (we started discussing such a "hook mechanism" in issue #94 but still made no progress there; so, even if we consider this approach as feasible, it would be a long way to go).

Other ideas are welcome, of course. If no one objects, I would first experiment with the submodel idea to get a first impression of the expected workload.