Opened 18 years ago
Closed 15 years ago
#145 closed enhancement (fixed)
Forcing function implementing Culverts
Reported by: | ole | Owned by: | ole |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | Functionality and features | Version: | 1.0 |
Severity: | normal | Keywords: | culvert flows |
Cc: |
Description
A forcing function that can add and remove water at arbitrary locations may be used to model culvert or pipe flows. This was suggested by Ruby Van Drie and would allow ANUGA to be incorporated in Hydrological modelling, e.g. with the WBNM model.
Rudy will visit on 9th of May, so it would be good to have a prototype ready by then.
Change History (4)
comment:1 Changed 18 years ago by ole
- Status changed from new to assigned
comment:2 Changed 17 years ago by ole
comment:3 Changed 15 years ago by ole
Allthough Culverts are almost there at the time of writing (August 2009), issues with reducing the flow when insufficient water is present at the inlet persists.
Ted Rigby wrote some thoughts about it in mails June 2009:
My understanding with both RMA2 and Fst2dH (both FEM) is that the culvert flow solution for conditions at the end of the current timestep is derived on an iterative basis (method of residuals) but the flow transfered is ultimately limited to the volume of the upstream elements connected to the culvert (cant create flow). The inflow elements can go dry at some point during the simulation (I have experienced that when I have had small elements attached) - In FEM models this tends to induce instability which sometimes produces the dreaded ' failed to converge' error message terminating the program. The standard 1D culvert equations assume a static (no or slow variation in flow) condition . In a timesteping situation this approach requires there to be no signifigant change in the flood levels upstream and downstream of the culvert during a calculation timestep if the flow is to be correctly computed. If the upstream elements are going dry in the model at a particular timestep (but not in reality) then the culvert flows can not be represented by a static relationship. At the next timestep the flow might well reverse producing culvert sloshing (did occur in some early FEM models ). Given the very small timestep in ANUGA it is hard to imagine this happening but could not the transfer function operate at a fraction of the current timestep to more realistically simulate the variation in inflow depth and culvert flow during the full timestep if the inflow element reduces significantly in volume when flow is conventionally computed.
Unfortunately the majority of softwares implementing culverts are now proprietary. The HEC-RAS, fst2dh and tuflow manuals do have a fair bit of background that might help. http://water.usgs.gov/software/FESWMS-2DH/ has the original FESWMS- flo2dh source code that implemented culverts but it is now a bit old. I am not sure where to look but the swmm - wspro programs are public domain and also have culvert code although being 1D they largely sidestep the attached elements volume consideration. flo2dh is probably the closest source facing the actual problem but the initial code did not even warn when the attached elements were going dry so it also may not be much help. The issue seems to be one of realistically representing the flow that can leave the upstream elements as flow depth decreases. This does not mean that the upstream elements can not dry out as water flowing out of a box will eventually empty the box - the real problem seems to be representing the assymptotically diminishing inlet head/flow relationship. This suggests to me a test to see if the upstream elements could go dry and if they do switching to a smaller timestep for the culvert. I know from comment made by Bill Symes that it is not uncommon to require a smaller timestep fot stable 1D calcs than for the 2D solution. . The soltion adopted by the current fst2dh seems to be to simply warn the user that the inlet elements have gone dry and the user should review (make larger or conect more nodes to the culvert). The code often goes unstable anyway at this point but it does not create volume - I am not clear how a model can acttually do that ??
comment:4 Changed 15 years ago by nariman
- Resolution set to fixed
- Status changed from assigned to closed
Much work done between changeset:5294 and changeset:5305 (8-9 May 2008).