So far, HydPy provides only "kinematic" routing approaches, which approximate the diffusion of flood waves by fine-tuning numerical diffusion but cannot account for backwater effects. Currently, this limits our capabilities in modelling the anthropogenically controlled flow regimes in northern Germany (Schleswig-Holstein), where terrains are very flat and sometimes even below sea level. Therefore, we decided to close this gap by introducing a new model family responsible for calculating 1-dimensional water movement in channels in a "hydrodynamic" manner by approximating the shallow water equations.

The first decision is already settled. Our first application model (or selectable mathematical approximation) will be the "local inertial approximation of the shallow water equations" introduced by Bates et al. (2010) and "stabilised" by Almeida et al. (2012). The method's original purpose is modelling inundations in two dimensions, but we see no reason not to use it for 1-dimensional routing. The authors provide 1-dimensional test cases (Almeida and Bates, 2013), wflow uses the original method after Bates et al. (2010) for river routing, and comparisons of a prototype with Sobek under simplified conditions were successful.

We are not aware of a catchy name for the method. We agreed spontaneously on Lias-1D (Local Inertial Approximation of the Shallow water equations). ("1D", in case we add a 2-dimensional hydrodynamic method to HydPy later).

In the following, we speak of Lias-1D for simplicity when referring to all potential members (or methods) of the new model family.

It is foreseeable that the new model family will heavily use the new submodel concept (#90), which still needs to be fully developed. However, for the same reasons discussed in #95, we prefer to add another example before finalising the implementation of all submodel functionalities. In cases like those covered by #95, each main model will likely always require at most one instance of a submodel of a specific type (e.g. to calculate potential evapotranspiration after Turc-Wendling). In contrast, for LIAS-1D, a main model (representing a channel network) might reference a higher number of submodels of the same type, for example, to model the effects of multiple weirs within the network.

LIAS-1D differs structurally from the already implemented routing methods because it needs to simulate the whole network of connected channels in parallel, so that water can flow in any direction. Hence, a first attempt would be to define one model instance of LIAS-1D per basin model. However, that could result in inconveniences. Usually, we differentiate a basin model into multiple selections, each reflecting the subareas and substreams between two gauges or above the most upstream gauge. This makes the model configuration files more manageable. And it allows modelling only specific subareas of a basin, which is very important for saving computation time.

Maybe we should allow defining multiple parts of the channel network in different control files. Each control file would correspond to a single Element instance and a single Model instance. Before starting a simulation, the separate LIAS-1D instances would have to connect. Unconnectable instances would instead require alternative boundary conditions. Would it make sense to define default boundary conditions in the control files that are only applied when no connections to other LIAS-1D instances are possible?

When allowing separating channel networks on different model instances, we need to find a way to trigger their parallel execution. A very first idea: We could introduce two new base classes, like ParallelController and ParallelModel. Method HydPy.update_devices searches for ParallelModel instances and hands them to a suitable ParallelController instance. When determining the execution order, it does not take the ParallelModel instances but only the ParallelController instances into account. During simulation, ParallelController would only have to control the execution of the ParallelModel instances. So, they also could be considered submodels.

Following this idea, it seems most likely that ParallelController and ParallelModel need to share much logic. So maybe it is preferable to derive LIAS-1D from ParallelModel and let it return an appropriate controller upon request. For the methodology at hand, the controller, for example, would have to determine the suitable numerical step size required to stabilise all ParallelModel instances.

Maybe, the same type of controller could work for different types of ParallelModel subtypes so that selecting different approximations for different parts of a channel network would work?

Many additional aspects require discussion, for example:

• What types of boundary conditions do we want to support?
• Which ways to define channel geometries should we support?
• Must the supplied geometries be ready for simulation, or do we implement some preprocessing (to, for example, allow changing the length of the individual river sections)?
• How can we structure such complex data in the usual control file format (or do we need another data format)?
• In the long run: Should we create a small GUI that helps structure and maintain the channel data (or is such a GUI already available that we could use)?

We must remember that HydPy focuses on catchment hydrology, not river hydraulics. So it's preferable to keep things simple from the hydrologist's perspective.