Three alternatives are illustrated:

1. Controlling the flow with a timeseries, e.g. historic gate operation is known and can be specified directly (as a timeseries).

2. Controlling the flow with a "Sample Rule" e.g. gate operation is tied to water level monitoring (within the model domain).

3. Controlling the flow with a "Target Rule" e.g. gate operation is tied water level monitoring (within the model domain) and a target water level timeseries.

! Timeseries Controlled Structure

structure == nodestring, 1

flux function == matrix ! hQh matrix

flux file == hQh.csv ! hQh matrix file

control == timeseries ! structure fraction open specified by input timeseries

control parameter == fraction_open

control update dt == 1. ! hr

control file == ..\..\bcs\pump\AQUIS_pump_inflow_control_tseries.csv ! csv file with column headers "TIME", "FRACTION_OPEN"

max opening increment == 0.1 ! maximum change in structure fraction open (per update timestep)

end structure

! Sample Rule Controlled Structure

structure == nodestring, 1

flux function == matrix ! hQh matrix

flux file == hQh.csv ! hQh matrix file

control == sample_rule ! structure control type

control parameter == fraction_open ! structure fraction open specified by water level monitoring and associated rule

control update dt == 1. ! HR

control file == control_rule.csv ! csv file with column headers "SAMPLE_VALUE", "FRACTION_OPEN"

sample type == WL ! sampling parameter (water level)

sample point == 364352., 8139574. ! sampling location

sample dt == 0.1 ! hr

max opening increment == 0.1 ! maximum change in structure fraction open (per update timestep)

end structure

! Target Rule Controlled Structure

structure == nodestring, 1

flux function == matrix ! hQh matrix

flux file == hQh.csv ! hQh matrix file

control == target_rule ! structure fraction open specified by water level monitoring, target water level timeseries and associated rule

control parameter == fraction_open

control update dt == 1. ! HR

target file == target_wl.csv ! csv file with column headers "TIME", "TARGET_VALUE"

control file == control_rule.csv ! csv file with column headers "TARGET_DEFICIT","FRACTION_OPEN"

sample type == WL ! sampling parameter (water level)

sample point == 364352., 8139574. ! sampling location

sample dt == 0.1 ! hr

max opening increment == 0.1 ! maximum change in structure fraction open (per update timestep)

end structure

]]>

The simulation runs ok, but I would like to know if this is being represented correctly, or if the mesh elevations should be set at, or lower than, the culvert invert elevations.

Attached figure should help clarify.

Thanks

]]>

I have some detailed HEC RAS models for a series of bridges in a river reach I am investigating. I've run a series of steady state conditions and established the head loss across each for a range of flow conditions.

The client has now asked me to investigate the dynamic response of the entire river reach during a flood event. To do this I've setup a TUFLOW FV model of the river channel and floodplain, and setup nodestrings at each bridge location.

How can I incorporate the head losses calculated from HEC RAS into my TUFLOW FV model? I'd prefer not to use the culvert + weir approach, which may end up giving me different head losses compared to HEC RAS.

Thanks

]]>

There is a complication in the weir flow calculation when the vertices of a cell face are of different elevations. If they are then the following checks are made:

- If the water level is higher than both vertices (H1 and H2), the crest level is (H1 + H2) / 2 (ie the average)
- If the water level is between the two vertices (H1 < WL < H2 for example), the crest level is adjusted so that the flow area of the weir (assumed to be flat across the face) is consistent with the actual flow area (which forms a triangle). H = (WL + H1)/2

The following diagram illustrates this adjustment.

]]>

During the setup stage of a simulation, TUFLOW FV performs a search of all cell faces to establish which ones will be assigned as autoweirs. A cell face becomes an autoweir if the face elevation is higher than the adjacent cell centres. Note that this considers the 2dm file vertices plus any additional cell elevation commands in the input file ("cell elevation polyline", etc). The parameter "P1" is included in this selection process.

The following diagram is a simple illustration of this.

Initial testing indicated that if I set P1 = 0 then a large number of cell faces in the model are activated as autoweirs (and they don’t need to be). Setting P1 = 0.1 appears sensible with tests I’ve performed.

]]>

But, TUFLOW FV will simulate weir flow using the standard shallow water equations (SWE). How accurate is this approach?

Consider the test with a broad crested weir which is 5 m high and 250 m across with a 1000 m^{3}/s discharge applied. Using the standard weir equation, the water level upstream of the weir is 6.765 m. Running a simulation without applying the weir equation (and using a Manning’s n = 0.018), upstream water levels can differ.

A series of tests were applied with various cell resolutions across the weir and compared to the “exact” solution from the weir equation. The tests and the resulting elevation upstream are shown in the following table.

As shown, the nodestring structure (test 4) perfectly matches the weir equation (test 6). The solution using the shallow water equations (SWE) tends to underpredict head loss across the structure. If the number of cells defined across the weir crest is increased, a more accurate solution is obtained. Note also that the solution is dependent upon friction (which is one of the dominant physical processes being simulated by the SWE, as shown in test 5).

Concluding, it is recommended that in situations where an accurate representation of weir flow is required a nodestring structure that inserts the weir equation into the solution scheme is used. In other situations, using the SWE (in other words, just letting TUFLOW FV simulate weir flow without any direction specification of weir structures) may be entirely acceptable. Importantly, the modeller should be aware that differences do exist between these two approaches.

]]>

]]>

I am trying to add a weir structure with a fixed crest level to my model. I have added an internal nodestring #3 and used the following syntax.

structure == nodestring, 3

flux function == weir

properties == 3, 1.6

structure logging == 1

end structure

The model comes up with the following error,

- Unrecognised structure type
- Unrecognised structure flag

Would you please help me with this problem?

Regards,