Methods

This section provides an overview of the setup for two Benchmark cases, which serve as baseline models for optimising hardware configurations in HEC-RAS 2D simulations. Details of setups and tests conducted on these two Benchmark cases, including different hardware configurations, as well as mesh, numerical solution, solving equations, and associated costs, are presented in the following.

Benchmark Case 1: The modelled area encompasses 2.83 km², covering a 7.96-km stretch of the River Chew and the village of Pensford in Somerset, UK (Figure 2a). To create a flood inundation map, the Unsteady Flow module of HEC-RAS 2D was employed. The upstream boundary was defined using a flow hydrograph, whereas the downstream boundary was set with a normal depth (corresponding to a friction slope of 0.009). A hydrograph for the flood event from 20 to 23 November 2016 was generated using HEC-HMS (Figure 2a). While Sabeti et al. (Reference Sabeti, Stamataki and Kjeldsen2024) provides a detailed discussion of the model setup and calibration, this study only offers a brief overview of the HEC-HMS model configuration. The Soil Conservation Service (SCS)-Curve Number method was used to account for hydrological losses, and the SCS Unit Hydrograph method was selected for hydrological routing. For river channel routing, the Muskingum method was employed. The model accurately reproduced the event, achieving a 73% match with the measured flow rate. A Digital Elevation Model provided by SCALGO (https://scalgo.com/) was used in our HEC-RAS 2D setup with the following specifications: A Digital Terrain Model that incorporates buildings but not vegetation, resolution of 1 m, and Lidar originated (Figure 2a). The model includes five bridges, specified in the Geometry section of the HEC-RAS 2D.

Figure 2.

HEC-RAS configuration: (a) River Chew, showing the water depth layer for the peak during the 20–23 November 2016 event. The Refined region in River Chew setup is applied only for Tests 15–18. (b) Bald Eagle Creek, depicting the water-depth layer for the peak during 01–09 January 1999.

In terms of the mesh, HEC-RAS 2D allows for the definition of varying mesh resolutions along with unstructured and structured (by default) meshes. The unstructured mesh consists of irregularly shaped cells with a maximum of eight sides per cell, offering greater flexibility in representing complex terrains and boundaries, although the irregularity in cell shapes and connectivity increases computational complexity. For the case of the River Chew, the initial setup used a structured mesh with a resolution of 10 m within the entire modelled area which was defined in the RASMapper. Accordingly, the first set of tests focused solely on the impact of hardware configurations on simulation time, using the River Chew setup with a structured mesh and a resolution of 10 m (Tests 1–9, Table 1). In order to determine whether increasing the number of cores improves the efficiency of simulation time in HEC-RAS 2D as the number of cells increases, a series of tests is designed, in which we varied the mesh resolution from 10 to 5, 2.5, and 1 m in River Chew case (Tests 10–15, Table 1).

Table 1.

Details of tests on the River Chew (RC) and Bald Eagle Creek (BEC) Example to assess the impact of CPU speed, number of CPUs, RAM capacity, Boot disk type (SSD vs. HDD), number of cells, numerical solutions (FV vs. FDC), solving equations (SWE vs. DWE), and mesh types on simulation time, along with the hourly cost of each virtual machine on GCP

¹ C2, E2, and C3 are different series of virtual machines on GCP, each with similar specifications. The number, such as the “2” in C2, represents the generation of the series.

² In the creation stage of the virtual machines, the virtual CPU-to-core ratio is configured to 1:1 (for all virtual machines), meaning each core is assigned one virtual CPU.

³ In GCP Boot disk setup, SSD Persistent Disk use SSD storage, while Standard Persistent Disk is based on HDD storage.

⁴ For the RC case, the number of computational cells increases with mesh refinement: 10 m mesh results in 37,866 cells, 5 m mesh in 169,749 cells, 2.5 m mesh in 573,698 cells, 1 m mesh in 1,532,276 cells, and a combination of 1 m mesh with a 0.5-m refined region results in 1,981,164 cells. In the BEC case, the mesh size is 250 m.

⁵ For all tests, the US-central1 (Iowa) region was selected for costing.

Additionally, we created a Refined region with a 0.5-m resolution covering the 0.071-km² residential area of Pensford, which has historically been affected by flooding (Figure 2a). The Perimeter spacing and Near repeats were set to 1 m and 4, meaning that for 4 m on either side of the Refined region, the mesh repeats the 1 m cells. The tests, including the Refined region, used an original mesh with resolution of 1 m covering the entire setup area, except for the Refined region. This modification was generated an unstructured mesh around the Refined region, allowing us to assess the combined impact of both very fine and unstructured meshes. Accordingly, a group of tests were designed to assess the impact of the speed of core and number of cores in simulation time within this setup (Tests 16–19, Table 1).

The initial setup of the River Chew case utilised the FDC method along with DWE. To evaluate the impact of the numerical solution, and solver equations, a series of tests was specifically designed to assess the performance of the alternative approaches, the FV method and SWOE (Tests 20–23 and Test 24–27, respectively; Table 1). These variations allowed us to evaluate the impact of different solver equations and numerical approaches on simulation time across different hardware configurations.

In the simulations of the River Chew case, the flow velocity ( $ v $ ) was 1.5 m/s. For the setups with mesh sizes ( $ \varDelta s $ ) of 10 m (Tests 1–9 and Tests 20–23), 5 m (Tests 10–11), 2.5 m (Tests 12–13), 1 m (Tests 14–15) (Table 1), and the setup with mesh size of 1 m and the Refined region of 0.5 m (Tests 16–19), the DWE was used. The time step ( $ \varDelta t $ ) for these tests was set to 10, 10, 5, 2, and 1 s, respectively, to satisfy the Courant number criterion $ C=v\frac{\varDelta t}{\varDelta s}\le $ 1.0 (with a maximum $ C $  = 5.0), as recommended by the HEC-RAS manual (Hydrologic Engineering Center, 2021), ensuring model stability. For simulations using the Shallow Water Equations (Tests 24–27), which impose a stricter Courant number criterion of maximum C= 3.0, the mesh size was 10 m and we set the $ \varDelta s $ to 10 s. Finally, the number of cores in the setup was matched with the number of the virtual machine or desktop PC cores, not “All Available” option. For instance, if the virtual machine’s core had 10 cores, we set the number of cores in the setup to 10.

Benchmark Case 2: For the second Benchmark Case, we utilised one of the official examples provided by HEC-RAS, specifically the Bald Eagle Creek Example (Figure 2b). Within this example, the “Single 2D Area with Bridges and Break-lines” scenario was selected. This simulation covers a region of 106.84 km² with a grid spacing ( $ \varDelta s $ ) of 250 m, resulting in 24,748 computational cells. The majority of the mesh was structured; however, certain regions, such as those with Breaklines (e.g., the area shown in Figure 2a within the main channel of this setup), were unstructured. The modelled area includes an urban region of 29.30 km² and features the Sayers Dam, seven bridges, and three levees. Regarding boundary conditions, we maintained the original setup, where the two downstream boundaries were both set to a normal depth, each with a friction slope of 0.0003, and the upstream boundary was defined by a flow hydrograph for the event occurring from 1 to 4 January 1999. It should be noted that the hydrograph in Figure 2b displays the full hydrograph from 1 to 9 January 1999. However, the original simulation period, from 1 to 4 January 1999, was retained as the default setting in our tests. In the Unsteady Flow Analysis settings, the time step was set to 5 s by default. In terms of the computational methods, the numerical solution was implemented using the FDC method. However, to ensure consistency with most of our tests on the River Chew (Benchmark Case 1), the solving equations in these setups (Benchmark Case 2) were set to DWE. The Bald Eagle Creek example was hydraulically more complex than the River Chew case due to its coverage of a larger urban area, the presence of a dam, multiple bridges, and levees. This foundation allowed us to conduct an additional series of tests to determine the optimal hardware configurations for efficient HEC-RAS 2D simulation time (Tests 28–36, Table 1).

Leveraging the ability to adjust the number of cores in the Computation Options and Tolerances section of HEC-RAS 2D, alongside the virtual machines (Tests 28–31, Table 1) a desktop PC was employed in our assessment (Tests 32–36, Table 1) to identify the optimal core number for minimising simulation time. Bald Eagle Creek example was used in Tests 32–36. This assessment was considered to provide insights for modellers who do not have access to hardware-adjustable virtual machines.

The desktop PC is also used to conduct Test 37 which allows for a comparison with Test 4 in terms of CPU speed, as both tests share identical conditions except for the CPU speed.

The setups of Tests 1–9 were designed to be identical in terms of numerical solutions, solving equations, and the modelled region (River Chew). Consequently, any variation in simulation time was solely attributable to hardware configurations. This design was created a foundation for conducting a hypothetical analysis based on the assumption of 1,000 simulations, which was a common scenario in uncertainty analysis using tools, such as the Monte Carlo approach. By extrapolating the time for a single simulation to 1,000 runs and calculating the total cost using the hourly rate, we assessed how different hardware configurations impact overall time and cost. This analysis highlighted the importance of an optimised hardware setup in HEC-RAS 2D models in large-scale simulations. To quantify this impact, we applied an efficiency score ( $ Es $ ) that incorporates both total time and total cost of simulations, with an equation derived from the approach presented in Fishburn’s (Reference Fishburn1979) study, as outlined below:

(1) $$ Es=1-\left({w}_{\mathrm{time}}\times \sqrt{n_{\mathrm{time}}}+{w}_{\mathrm{cost}}\times \sqrt{n_{\mathrm{cost}}}\right) $$

where $ {w}_{\mathrm{time}} $ and $ {w}_{\mathrm{cost}} $ are the weights assigned to time and cost, respectively. Both weight values were set to 0.5 in this analysis, giving equal importance to each. $ {n}_{\mathrm{time}} $ and $ {n}_{\mathrm{cost}} $ are the normalised values of total time and total cost, derived for each test using min–max normalisation method as described by Amiri et al. (Reference Amiri, Akanbi and Fazeldehkordi2014).

Normalised Sensitivity Coefficient (NSC) (Equation 2) was used as a sensitivity analysis index (Hamby, Reference Hamby1995), to quantify the sensitivity of an output variable (i.e., simulation time) to changes in input parameters (i.e., hardware configurations). NSC nondimensionalises parameter sensitivity, allowing for direct comparison and ranking of the most influential variables.

(2) $$ NSC=\frac{\Delta SimT/ Sim{T}_0}{\Delta {p}_i/{p}_{i0}}\times 100 $$

where $ SimT $ is the simulation time, $ {p}_i $ is the input parameter (i.e., RAM), and $ Sim{T}_0 $ and $ {p}_{i0} $ are the reference values of the simulation time and the input parameter, respectively. The tests used in this assessment were from Tests 1–9 and Test 37, with the setup of River Chew (Benchmark Case 1).