Development of a Hydraulic Modelling Platform Within an Open-Source Environment

Abstract

Flood risk management represents a true technical challenge because of complex interactions between a variety of physical, environmental and economic factors. Appropriate computational modelling may prove very useful to understand underlying physical phenomena, appraise scenarios and devise overall management schemes encompassing catchment basins and city areas. There is a continuing tendency towards merging hydraulic modelling with advanced numerical technology, such as database linked to measuring data or patrimonial data, GIS, more and more accurate ground elevation models, real-time control which implies strong interaction between monitoring platforms, measurement networks and hydraulic modelling software. It is therefore necessary to use modelling software connected to standard software components (database and GIS frameworks) in order to take best advantage of these data. Besides, public clients favour hydraulic models which are developed with free software components in order to ensure their sustainability and updating, as recalled by the French government note 5608/SG from 19 November 2012. In order to comply with this double requirement, Setec Hydratec has developed new model interfaces in an open-source environment: Hydra platform, in collaboration with Oslandia and IGN.

1 A Modelling Architecture Best Fitted to the Complexity and Diversity of Geographical Scales of Hydraulic Systems

Water management and associated risks represent a real challenge to urban development. Inland and coastal areas are subjected to numerous hazards: marine submersion, river overflow and saturation of drainage networks in case of heavy rainfall.

Hydra software has been developed to model these hydro-meteorological factors within a unique modelling unit in order to provide a good understanding of the various physical interactions and to devise and test appropriate technical solutions.

Numerical modelling software is intended to describe physical system behaviour through an appropriate set of equations. This is a simplified approach which should be adapted to the geometric and physical reality and to the modelling objectives.

Modelling schemes are not unique; they should be adapted to the specific issue to resolve: estuary bodies subjected to marine intrusion are best modelled through a continuous 2D mesh scaled on bathymetric data, whereas river and drainage system modelling is strongly dependent on the numerous singularities and hydraulic works.

Contrasted interacting modelling schemes are therefore proposed in Hydra software, and each of them is intended to be best fitted to the geographical scale and configuration of the physical system:

• one-dimensional modelling: drainage and sewage networks and combined river flow along a valley are defined by geometric sections along a preferential flow direction;

• Two-dimensional modelling: surface ground or bathymetry is modelled by a continuous mesh; each cell is defined by its area and average ground elevation;

• storage areas: expansion zones within where flow velocity is small; they are defined by tabulated curves relating area to water elevation;

• streets and favoured axes for flow propagation in a dense urban environment: this configuration requires specific modelling where one flow direction dominates;

• plants, complex works and control stations require specific modelling; and

• watersheds and secondary networks where hydrologic modelling laws apply.

These various domains are interconnected through a large panel of hydraulic links of different nature as shown in Fig. 1.

Fig. 1

Available modelling schemes in Hydra simulation code

In 2D domains, specific modelling of singularities with links allows to apply fairly loose meshing and thus to reduce computation time while retaining numerical accuracy. In Hydra code (Ref. [1]), two solving schemes for the free-surface flow equations are available within a model:

• complete resolution of St Venant equations: three independent variables are considered for each calculation node for a 2D domain (water elevation and flow velocity component in each direction) and two variables for 1D domain (water elevation and flow velocity along the privileged flow direction); and

• simplified resolution: convective terms are neglected, which allows to uncouple equations and to consider just one independent variable to be computed at each time step (water elevation at each node). This simplification results in appreciable computation time gains but it is valid only for a restricted class of flow configurations.

Being able to choose the most appropriate solution, mode for each sub-domain ensures strong flexibility to the user and is found to be of primary practical importance in managing large models composed of contrasted sub-regions and for which many computation runs are required.

2 Development Environment of Hydra Interface

2.1 Environment

The initial objective was to facilitate the use of Hydra software by developing a user-friendly interface. It has been finally decided to build this interface on an existing GIS rather than to develop a specific pre- and post-processor.

QGIS environment was chosen to build the application: this is a high-quality GIS software (Geographical Information System) which is open-source and multi-platform (published under GPL license). This software allows to create business applications and to federate a community of developers.

The second step was to define a conceptual geodata model compatible with the GIS platform. This is a crucial task which conditions the flexibility and the reliability of the whole project: simple data storage has evolved into new topological and geographical concept from which model elements are derived. This evolution allows to capitalize business skills while ensuring data integrity for computation purposes.

The model architecture and all relevant model data are stored in a PostGRE geodatabase, thanks to its spatial extension PostGIS, both are also open source and can be easily accessed from QGIS.

‘Instead-off’ triggers are coupled to SQL views to create a true API for the database base: meshing and computational result processings are performed through specific functions added to the database (plpyton, fdw).

This approach allows to optimize exchanges between the business code and the database and to ensure data integrity for all interactive tasks. Integrity is controlled when data is entered in the database; this ensures upstream data quality for the subsequent treatments and facilitates exchanges with external clients for model interaction.

QGIS is used in this context as a graphical pre- and post-processor; all of its functions remain available to the user. Specific developments are made possible by QGIS plugins mechanism and are intended to maximize ergonomic aspects. Especially useful are the possibilities offered by the interactive cartographic visualization of computation results (data refreshing cycle >60 Hz, Ref. [2]).

2.2 Conceptual Geodata Model

The conceptual geodata model reflects modelling concepts presented above:

• specific ‘containers’ are defined for each category of sub-domain; they are transformed into computation nodes during calculation;

• containers are interconnected through ‘link’ elements: these provide appropriate flux connections between containers; and

• hydraulic singularities are placed on a container: they represent hydraulics works along a 1D reach or branch, or a boundary condition.

For each of these categories, data are stored in set of two tables: an abstract table, defined for each category: it is the parent table and contains attributes which are common to all derived tables within the category. Each derived table contains attribute data to the specific physical object to be modelled. For those familiar with object-oriented programming notion, this is a relational implementation of the concepts of inheritance. This architecture has proved to be fairly powerful, and it provides great flexibility for the database evolution and maintenance.

The data model also contains specific tables for scenario settings.

This user description is general and does not depend on the solving scheme: proper interpretation of user data is made during the computation stage; it depends on the computation options defined by the user in the scenario settings interface.

2.3 Creation, Edition and Visualization of Modelling Components

The user’s interface is designed as a QGIS plugin; it interacts with the geodatabase. A view is created for each object which is defined in the data model and can be displayed/hidden in QGIS with the layer manager. Specific tools have been developed to create objects and edit their characteristics.

The picture below shows the user’s plan view and the list of buttons (left panel) to create objects. A graphical window to visualize and edit an object is also shown (hydraulic gate in this case) (Fig. 2).

Fig. 2

Plan view of the QGIS user interface with model element and edit graphic window

2.4 Computation Monitoring, Results Processing

The user’s interface provides all necessary tools to define scenario settings, activate runs and process computation results: longitudinal water elevation and flow rate profiles along a 1D reach or network branch, hydrographs/water elevation time history at each node, spatial maps representing water levels and flow velocity distribution, specific results pertaining to each model element, location of overflows and associated overflow volumes, etc.

The picture below shows examples of results visualization (bottom: longitudinal profile, window: flow evolution at a node) and also the layer manager (left panel) (Fig. 3).

Fig. 3

QGIS user interface with layer manager and result panels

3 Underlying Concepts and Implementation of a Model

3.1 Underlying Concepts

Model implementation in the field of free-surface flow, and especially river flow, is based on original concepts which allow the user to concentrate on the physical understanding of the system to be modelled and let the application generate all the modelling components necessary for computational purposes.

This concept reflects a high degree of integration: surface flow is usually constrained by complex topographic features and obstacles which must be identified in order to define a model scheme best fitted to geographical context and also to the specific modelling objectives. These singularities include the following:

• Hydro-geomorphological features pertaining to a river system: channels and rivers with banks, floodplains with preferential flows, expansions areas, etc.;

• physical obstacles (levees, dykes) and slope transitions;

• drainage works; and

• land use: vegetation, built areas, etc.

In a model construction process, the first step is to delineate all these singularities as constraint lines. For each of those, one defines as follows:

• the singularity type: boundary, floodplain transect (used to generate geometrical section for river ID modelling), river banks;

• type of hydraulic links across each singularity line: 2D, overflow and porous; corresponding geometric parameters are computed by the application; and

• desired scale for each modelling element: average cell size for 2D domains, average width of lateral link between 2D domains, etc.

These constraint lines are contiguous and delimitate closed regions which span the whole domain. These polygons form a coverage of the modelling domain and are given specific modelling properties by automatic inspection of physical properties of the included modelling elements (reach, storage, street, etc.). When none of those elements is included, the domain is meshed with 2D elements.

Principles of coverage generation are illustrated as follows (Fig. 4).

Fig. 4

Principle of coverage generation

2D meshing is then generated by the database with an underlying call to GSMH (Ref. [3]), followed by an SQL function call to create hydraulic link elements between cells and across line singularities. From the user perspective, this is a simple click in the domain.

These operations take full advantage of topographical data from LIDAR or ground survey since the geodatabase has been made DEM-aware through added SQL functions. In addition, to help the user understand the terrain, QGIS provides tools to analyze these data and allows for spatial visualization. These tools are very useful to draw constraint lines induced by topography.

The example below illustrates the capability of the application in generating all the modelling elements required for computation. In Fig. 5, the user only defines the constraint lines necessary to the physical definition of the model. The application creates 1D and 2D domains coverage, 2D meshing and all links between coverages; geometric and topographic attributes of each generated object are computed by the application.

Fig. 5

Example of coverage distribution

The next example below is taken from a real application: one can see the constraint lines, polygons of the coverage and links generated between polygons (Fig. 6).

Fig. 6

Distribution of coverage polygons on a real application

This construction process is dynamic and fully interactive: the user can delete meshing within a polygon; he can introduce new constraint lines within a 2D domain and refine mesh size within any polygon at any time. Local singularities or waterworks (gate, pumps, weir and culvert) can be defined and positioned by the user at the beginning of the modelling process. They will be connected to the model after generation of the other modelling elements by the programme.

3.2 Example of Implementation

The following example illustrates methodology for constructing a river model combining 1D and 2D sub-domains.

3.2.1 Construction of 1D Domain

Steps are as follows:

• 1. drawing of the reach centre line with the river tool;

• 2. drawing of cross-sectional profile with the constraint line: section profile geometry is generated via the DEM (LIDAR in this example) and data from bathymetric survey (river geometry);

• 3. drawing of constraint lines to define general direction of the valley. The lines are not necessary for the computation but they are used in the cartographic result postprocessing along with the DEM data;

• 4. drawing of constraint lines along external frontiers of the floodplain; and

• 5. The application takes over and creates polygonal coverage (Fig. 7).

  Fig. 7

  

  Generation of 1D coverage polygons

3.2.2 Construction of 2D Domain

Steps are as follows:

• 1. creation of constraint lines along the boundaries of the 2D model. Mesh size is defined in each constraint line. In order to specify different mesh sizes, constraint lines may be subdivided into distinct lines which are connected at extremities. A coverage is then created automatically;

• 2. constraint lines can be added inside a polygon to model a line singularity (e.g. dyke or levee) or to constrain locally the size or direction of the mesh. In the example below two coverages are created; and

• 3. meshing is created in an interactive manner within each polygon.

The mesh can be generated automatically for all polygons if the need arises, no user interaction is actually required. The one-by-one interactive process is used to check the quality of the model while progressing in the modelling. ‘Finished’ zones are easily identifiable with the presence of 2D elements and/or generated links (Fig. 8).

Fig. 8

Generation of 2D coverage polygons

3.2.3 Construction of Street Domain

Steps are as follows:

• 1. creation of street centerline and definition of street width and linear friction;

• 2. constraint lines surrounding the street line and street coverage are created automatically; and

• 3. links with 2D domains and meshing in connected 2D domains are generated automatically (Fig. 9).

  Fig. 9

  

  Generation of street coverage polygons

4 Conclusion

Hydra software platform offers a complete set of modelling tools in the field of free-surface flow. This platform is coupled to a computational code designed to cover the practical needs of engineers. Hydra simulation code has been developed and maintained for the last 30 years and has been restructured recently to address a large panel of applications in hydrology and hydraulics modelling. Underlying formulation is detailed in Ref. [1].

Development of the Hydra interface relies on open-source GIS components and a geodatabase. It combines business skills and advanced concepts in conceptual data modelling and model implementation. This approach favours creation of a dynamics around a community of developers to further enhance the performance of the existing software, to enrich this application with additional features and to host other computation codes in addition to the Hydra simulation code.