Sometimes we may need to impose specific time series input for pre-defined locations. This option is quite frequent when configuring atmospheric forcing in a flood model – particularly rainfall depth property.
In this section we will illustrate how to properly prepare and create a rainfall depth timeseries input file, and how to configure the model to be able to ingest it in the whole spatial domain (rainfall constant in space). OpenFlows FLOOD also allows to impose rainfall depth or intensity, any of them variable in space and time based on multiple rainfall time series instead only one in the whole domain – but we don’t describe those advanced options in this generic guide – a specific guide on this thematic will be later generated and shared in Bentley Communities.
We will exemplify this application based in the existing dataset from Graz, and then we will create a new simulation.
You can download in Bentley Communities a sample workspace with time-variable rainfall (and constant in space)
Figure 1 – Creating a new Time Series File inside OpenFlows FLOOD
Figure 2 – Opening the created Time Series file
Figure 3 – Visualizing the TimeSeries file in File Editor
You will observe that the created timeseries file has 5 initial keywords, and after that, a block BeginTimeSerie/EndTimeSerie where the first column is the instant and the second is in fact an air temperature timeseries. The details about the keywords are described next:
As regards to the contents inside the block BeginTimeSerie/EndTimeSerie, above that block you can see a line with the headers of the column names (by default the created timeseries file generates a line with “hours” and “air_temperature”) – this is not read by the model and is merely informative for the user. If we delete this line, there is no impact on the model running in any way.
Now we need to edit the file in order to represent a valid rainfall event: For now, the easiest way will be to copy the data from “rainfall.srm” timeseries file to “rainfall_2.srm” (however, the user can later insert any other data as desired) . To do so, follow the next procedure:
Figure 4 – Copying content from one timeseries file to another one
Now we have successfully finished the generation and configuration of a new rainfall timeseries input file. The next step is to configure the model to consume the spatially constant and timely variable rainfall depth timeseries as a boundary condition.
We will show how to configure the model to be able to ingest the previously generated rainfall depth timeries in the whole spatial domain (rainfall constant in space). This will be illustrated with a new simulation:
Figure 5 – Creating a new simulation
You will find that under the created simulation, 6 module data files are generated. The main difference from the other existing simulation (Sim #1) is the module data file relative to atmosphere data file (Atmosphere_2.dat):
Figure 6 – Existing modules in “Sim #2 – variable rainfall”
The next step is to edit the Atmosphere module data file (Atmosphere_2.dat):
You can find an active block <beginproperty>/<endproperty> with the “NAME” keyword defined as precipitation. This block is created by default, and is predefined to impose spatially and temporally constant rainfall depth single value. We will also find an inactive / commented block named “precipitation” defined to read a timeseries rainfall depth file. The main differences from the other active block in terms of KEWORDS are:
Thus these are the main differences between a property block configured to impose a constant (over space and time) property value, or to read variable values in time (and constant in space) from a specific file. We just need to disable (comment) the active block and activate (uncomment) the other one. That can be done by:
The modified version of Atmosphere_2.dat is as follows:
Figure 7 – File Editor: Atmosphere_2.dat module data file
Finally, we need to edit the Basin module data file (Basin_2.dat) to activate the Atmosphere model:
We are now ready to run a simulation of a 1D-2D rainfall-runoff model application:
Note that running this model simulation with rainfall increases the computational time in 3 or 4 times compared to the simulation without rainfall.
Figure 8 – Layer Style properties menu – configuring min. value to 0.05
If you use 0 or very small minimum values, since we are now simulating rain-on-grid, it’s difficult to interpret the results, because almost all grid cells will have at least a small amount of water in the surface.
As final result, in the time instant 2010-1-1 12:00, you should obtain something similar to this map:
Figure 9 – Mapped output on water column for instant 2010-01-01 12:00 (simulation with direct rainfall)