Child pages
  • OpenStreams: Open Source Components as Building Blocks for Integrated Hydrological Models
Skip to end of metadata
Go to start of metadata

The OpenStreams vision: a collection of building blocks for integrated modelling

OpenStreams provides the building blocks for integrated water-related models. While a model usually represents processes for one domain in the water cycle (e. g. rainfall-runoff, groundwater flow or channel flow), integrated modelling means to connect multiple models for different domains, such that the interaction processes between the domains are taken into account. A classical integrated modelling case is the modelling of surface-subsurface water interaction, where an open channel flow model is connected to a groundwater model. The bank storage is the interaction processes between those domains, resulting in flood wave damping in the surface water domain and groundwater level rise in the groundwater domain.

The main goals of the OpenStreams are:

  1. Facilitate integrated modelling, i. e. modelling of multiple processes in an integral way, and modeling the interactions between these processes
  2. Usage of modeling tools in different frameworks and settings (e. g. using a computational core for rainfall-runoff-modelling within a modeling environment like DeltaShell and within a Delft-FEWS decision support system), thus reducing the effort in maintaining model code
  3. To provide a number of cases (applications) that demonstrate the use of model coupling and how the components can be used in projects and existing pieces of software. Here we also look at programming language barriers as the components we use are written in different programming languages.

When to use OpenStreams?

  • Integrated modelling helps to better understand of processes, in particular interaction processes between different domains.
  • Modelling human interactions (control) on physical systems (water systems like channel networks or reservoir cascades) can be realized as integrated modelling. Application cases range from operational management over planning studies to decision support systems.
  • Connection of models for physical processes with effect modules within the frame of integrated Water Resources Management

OpenStreams uses different frameworks and interface standards

Models are used in different environments and for different purposes. A rainfall-runoff model can for example be used within an operational forecasting system for flood risk management, to generate boundary conditions for a design study for dikes, or to support strategic planning decisions within the context of Integrated Water Resources Management. Consequently, OpenStreams uses multiple frameworks and interface standards. Ideally, a model component can be used in Deltashell, Delft-FEWS, OpenDA, in OpenMI- or BMI-compositions and in experimental frameworks that are coded for a specific purpose. This means that each OpenStream component must expose it's functionality in an API that allows the framework in which it is to be wrapped in to completely control the model.

There are a number of frameworks available for linking (hydrological) models (for example OMS:, OpenMI:, CSDMS:, hydromad:, Deltashell, Open source integrated modeling environment Delta Shell, EGU2012-13183). In OpenStreams we do not want to build another framework, instead we try to build up a set of components that can be used with different frameworks to maximize the reuse of the components. For this to succeed it is crucial that the API provided by the components provides an interface that allows a high level of control over the model. The amount of detail should be more than that needed by the different frameworks. Figure 1 shows how models that provide a low level API can be linked using wrappers to different frameworks such as OpenMI for linking models and data assimilation and calibration using OpenDA (, EGU2012-4039, this session). In addition, very close integration using the native API remains possible.

Figure 1: Diagram showing two models that provide a low level API.

  • No labels