UK EA benchmark 2 (Water Module)

This page reports on the performance of the Tygron Platform's Water Module by means of the UK EA Benchmark Test 2 – Filling of Floodplain Depressions.

Italic text blocks are largely based on the description in Néelz and Pender (2013) and Smith et al. (2019).

The test has been designed to evaluate the capability of a package to determine inundation extent and final flood depth, in a case involving low momentum flow over a complex topography.

Description

Fig. (a): Map of the DEM showing the location of the upstream boundary condition (red line), ground elevation contour lines every 0.05 m and output point locations (crosses).

The area modelled, shown in Fig. (a), is a perfect 2000 m x 2000 m square and consists of a 4 x 4 matrix of ~0.5-m deep depressions with smooth topographic transitions. The DEM (digital elevation model) was obtained by multiplying sinusoids in the north to south and west to east directions, and the resulting depressions are all identical in shape. An underlying average slope of 1:1500 exists in the north to south direction, and of 1:3000 in the west to east direction, with a ~2-m drop in elevation along the north-west to south-east diagonal.

The inflow boundary condition was applied along a 100-m line running south from the northwestern corner of the modelled domain, indicated by a red line in Fig. (a). A flooding with a peak flow of 20 m³/s and time base of ~85 minutes was implemented according the hydrograph in Fig. (b). The model was run for 2 days (48 hours) to allow the inundation to settle to its final state.

Fig. (b): Inflow hydrograph, which functioned as upstream boundary condition

Initial and boundary conditions

• Initial condition: dry bed
• Inflow along the red line in Fig. (a). Location and tables provided as part of the dataset
• All other boundaries are closed

Parameter values

• Manning’s n: 0.03 (uniform)
• Model grid resolution: 20 m (i.e., ~10 000 nodes within the area modelled)
• Simulated time: 48 hours

Technical setup

The required DEM is provided as an ASCII file (test2DEM.asc). As its cell size is 2 m, whereas the test is expected to be run on a 20-m grid, it will be automatically rescaled by the grid rasterizer. The dimensions of the test area must be 2000 by 2000 m. The original DEM had an offset of -200 m, which was cropped down to -20 m (= 1 grid cell) so it could function as border cell. The rescaled and cropped ASCII file is contained in the "" provided at the bottom of this page.

• 

  Original 2-m heightmap (2400 m x 2400 m)
• 

  Cropped and rescaled to 20-m grid (2040 m x 2040 m). The black perimeter designates the border cells.
• 

  Inlet series in the upper left corner.

In order to regulate the water level according to the water-level graph, the following setup was used: Inlet objects were placed on single grid cells with a constant value for x = 1 and y varying from 1 to 5, yielding a total of 5 points. The inlets were configured as follows:

• External area (m2): 1 000 000 000
• Water level (m): 1
• Threshold (m): none
• Inlet Q (m³/s) : 20 in total, thus 4 per inlet

Hydrograph for each individual inlet.

Output as required

Stats

• Software package used: Tygron Platform
• Numerical scheme: FV (Kurganov, Bollerman, Horvath)*
• Specification of hardware used to undertake the simulation:
  • Processor: Intel Xeon @2.10GHz x 8,
  • RAM 62.8 GiB,
  • GPU: 2x NVidia 1080
  • Operating system: Linux 4.13
• Time increment used: adaptive:
• Grid resolution: 10 m.
• Simulation time:
• Object flow: 96985.64 m³/s
• Remaining volume water: 96982.30 m³/s

Test results

Point graph measurements from the Tygron Platform (left) and other packages (right):

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

• 
• 

Last frame

• 
• 

Final timeframe of water levels as generated by the Tygron Platform (left) and by the other packages (right).

Notes

• Tests were run with a multi-GPU setup. For small cases like this, using single GPU actually leads to faster results. Furthermore, requesting a high number of 576 timeframes further bogs it down. In comparison: 1 GPU with 1 resulting timeframe runs in: 8 s, which is +- 53% faster compared to 2 GPUs with 576 timeframes.