Calculate the flow from/to a surface model #111
Comments
|
I think that it could be implemented in the following way, by using orifice and weir equations to calculate the flow: A function that loop through the nodes, calling another function for each node:
To calculate the flow, the main function needs to be aware of two values from the surface model:
This could be done in two way:
I think that the first option my be the best, as the AoS could contain the calculated flow, as a feedback to the surface model. The TNode struct should have new values added:
A more advanced way could be to link to another "manhole cover" object, that would determine those coefficients and the manhole shape. Those values influence the actual flow My knowledge of the SWMM code base is not very deep, so I'd be glad to have the opinion of other developers on that. It might be adequate to use ExtInflow for the calculated flow, as it could transfer pollutants. However, could ExtInflow be negative in case of outflow? |
|
Some theory on the use of weir and orifice for the flow calculation are found here: I would propose to simplify the solution described in this paper by using only the orifice equation when the node is overflowing. This solution as been proven with comparison to a physical model:
|
|
I would expect that there would be a benefit to having BOTH the Weir and orifice equation applying, as described in many texts such as the 1956 John Hopkins University "The Design of Storm Water Inlets", whereby the opening operates as a weir, until it is drowned and then acts as an orifice. For this to occur an effective weir length L is required and an effective clear opening area A (accounting for bars etc.) Noting that at times there may be two sets of these required for say a Grated Opening plus a Kerb Inlet. The Alternative approach is a RATING Curve. Note also that application of a Blockage factor or functional would also be very useful. |
What I propose:
However, different authors use different combinations, and it does not seems that there is a definite answer to that. For the weir length and opening area, I was thinking that we could start with a simplified model that:
However, in reality the lid is usually smaller than the actual manhole, and a more complex system might be useful. It is what I was referring to when proposing the addition of a "manhole cover" object. This object could contain the following information:
Of course, the reality is more complex, and there are way to represent it more finely. For example, see this article about drainage and overflow from various inlets, and taking into account the lifting force of the manhole cover:
However, implementing a solution like this might be much more complex, and we have to evaluate the its actual benefit. For a software like SWMM that is usually used on a large scale (city-wide), I'm not sure if it is worth the pain.
That would be indeed interesting. Do you have any literature recommendation on that matter? |
|
In Australia there are a few papers on Culvert Blockage (more so than pits) however many local authorities require a blockage factor to be applied when undertaking analysis. I will try and track down resources. For example Wollongong City Council specifies 50% and 80% blockage in: http://www.wollongong.nsw.gov.au/council/governance/Policies/Wollongong%20DCP%202009%20Chapter%20E14%20-%20Stormwater%20Management.pdf However the notion of using a Factor on the calculated flow (Q) for the pit inlet capacity is useful, for both analysing the impact of blockage, but also testing the system with say a Factor of 2 to double the capacity (to easily assess impact of doubling the pit capacity). |
|
@RudyFrom3 It seems to me that those documents are more like general design guidelines that call for a "safety factor", more than the actual occurring clogging, and even less how the blockage build-up in time during an event. [1] Inefficiency of storm water inlets as a source of urban floods |
|
As for representing multiple inlets, creating multiple smaller junctions (see #112) might be the easiest way to do it, instead of setting complex multiple-linking elements. |
|
I would have thought that the NODE simply be given some surface OPENING characteristics that define how FLOW from the surface enters the NODE. The NODE is simply a small storage that is part of the the internal transfer between links, and allows for additional surface flow to enter through the OPENING that is on the surface. Typically the opening would act as a weir initially and then at some higher depth act as an orifice. (Or it could be described by a rating curve Depth Versus Flow) |
|
@RudyFrom3 I agree with you. That is why I was proposing a a "manhole cover" object. See my post above.
But this does not negate the need of a way to set the manhole (not opening) area individually. |
|
The only reason I think it would be useful for the Manhole Lid Object to have Multiple Child Objects that represent openings is as in the following example: Etc.... |
|
@RudyFrom3 Maybe one As a first step, we could consider that the nodes are circular and have one opening of the size of the node But, the |
|
Another thing to think about is what happen to the overflow and ponding calculations that are already present in swmm. |
|
I'm working on an implementation. It might take some time before it is functional. |
|
You should also worry about what happens when a manhole surcharges as it shifts to a new node solution when the depth in the node is above the ycrown of the highest connecting link to the node. It might be cleaner to just have storage nodes connect to a 2D mesh. |
|
@dickinsonre Thank you for your comment. |
|
A quick answer and a better answer is to took at the EPA Hydraulics manual for SWMM5, Lew Rossman does a great job of presenting HOW the Surcharge solution is different than the normal node continuity equation. Here is a link as well as on OPENSWMM.ORG |
|
Thinking about this more there might be a simple flag that can be added to make the solution for storage or surcharged node transparent to the user. A key engine parameter is called yCrown (the crown of the highest connected pipe to a node), The program shifts to the surcharge algorithm at 0.96 * yCrown. If you change the code so that a 2D node has a yCrown above the rim elevation of the node then the surcharge algothim will not be used for node but the normal node continuity equation with the default surface area. Regarding the weir vs orifice, i would suggest a weir only for the following reason
Image is shown below |
|
@dickinsonre Thank you ery much for your comments.
I read the relevant part in the swmm hydraulic manual. I think I understand HOW the codes that update H for surcharged node and storage nodes are different. What I still fail to understand is WHY it is different. In dynamic wave routing, a node will always have a
That is indeed a neat idea. The drawback is that those nodes will never be reported as surcharged, I guess. The other option would be to create another class of node, but it will imply large changes in the engine.
I was thinking of simply hard-coding the weir and orifice equations in the coupling function. But it could make sense to re-use the swmm weir/orifice equations. |
|
It is always better to use the existing code. You can automatically make a new orifice and/or weir in the engine to communicate flows. Key code from SWMM5 for the handling of the calculation of depth in junctions, storage nodes etc void setNodeDepth(int i, double dt)
//
// Input: i = node index
// dt = time step (sec)
// Output: none
// Purpose: sets depth at non-outfall node after current time step.
//
{
int canPond; // TRUE if node can pond overflows
int isPonded; // TRUE if node is currently ponded
double dQ; // inflow minus outflow at node (cfs)
double dV; // change in node volume (ft3)
double dy; // change in node depth (ft)
double yMax; // max. depth at node (ft)
double yOld; // node depth at previous time step (ft)
double yLast; // previous node depth (ft)
double yNew; // new node depth (ft)
double yCrown; // depth to node crown (ft)
double surfArea; // node surface area (ft2)
double denom; // denominator term
double corr; // correction factor
double f=0.0; // relative surcharge depth
// --- see if node can pond water above it
canPond = (AllowPonding && Node[i].pondedArea > 0.0);
isPonded = (canPond && Node[i].newDepth > Node[i].fullDepth);
// --- initialize values
yCrown = Node[i].crownElev - Node[i].invertElev;
yOld = Node[i].oldDepth;
yLast = Node[i].newDepth;
Node[i].overflow = 0.0;
surfArea = Xnode[i].newSurfArea;
// --- determine average net flow volume into node over the time step
dQ = Node[i].inflow - Node[i].outflow;
dV = 0.5 * (Node[i].oldNetInflow + dQ) * dt;
**# // --- if node not surcharged or the node is a storage node , base depth change on surface area**
if ( yLast <= yCrown || Node[i].type == STORAGE || isPonded )
{
dy = dV / surfArea;
yNew = yOld + dy;
// --- save non-ponded surface area for use in surcharge algorithm //(5.1.002)
if ( !isPonded ) Xnode[i].oldSurfArea = surfArea; //(5.1.002)
// --- apply under-relaxation to new depth estimate
if ( Steps > 0 )
{
yNew = (1.0 - Omega) * yLast + Omega * yNew;
}
// --- don't allow a ponded node to drop much below full depth
if ( isPonded && yNew < Node[i].fullDepth )
yNew = Node[i].fullDepth - FUDGE;
}
// --- if node surcharged, base depth change on dqdh
// NOTE: depth change is w.r.t depth from previous
// iteration; also, do not apply under-relaxation.
else
{
// --- apply correction factor for upstream terminal nodes
corr = 1.0;
if ( Node[i].degree < 0 ) corr = 0.6;
// --- allow surface area from last non-surcharged condition
// to influence dqdh if depth close to crown depth
denom = Xnode[i].sumdqdh;
if ( yLast < 1.25 * yCrown )
{
f = (yLast - yCrown) / yCrown;
denom += (Xnode[i].oldSurfArea/dt -
Xnode[i].sumdqdh) * exp(-15.0 * f);
}
// --- compute new estimate of node depth
if ( denom == 0.0 ) dy = 0.0;
else dy = corr * dQ / denom;
yNew = yLast + dy;
if ( yNew < yCrown ) yNew = yCrown - FUDGE;
// --- don't allow a newly ponded node to rise much above full depth
if ( canPond && yNew > Node[i].fullDepth )
yNew = Node[i].fullDepth + FUDGE;
}
// --- depth cannot be negative
if ( yNew < 0 ) yNew = 0.0;
// --- determine max. non-flooded depth
yMax = Node[i].fullDepth;
if ( canPond == FALSE ) yMax += Node[i].surDepth;
// --- find flooded depth & volume
if ( yNew > yMax )
{
yNew = getFloodedDepth(i, canPond, dV, yNew, yMax, dt);
}
else Node[i].newVolume = node_getVolume(i, yNew);
// --- compute change in depth w.r.t. time
Xnode[i].dYdT = fabs(yNew - yOld) / dt; |
|
based on #124 being closed off, I am assuming that the weir/orifice connection to SWMM is now operational and that the stumbling block for 2D models now is only on how to link the exchange of information to and from SWMM? So to drive the Weir/Orifice a value of depth is required that is representative of the depth over a pit Top. For Pits that Surcharge, the Flow from SWMM needs to be passed back to the 2D model. There is the third required component.... Once the depth is passed, the Weir/Orifice calculation identifies a Flow, which may or may not be excepted by the connecting pipe link. So a secondary calculation is required in SWMM to identify that the Pipe has the capacity to except the total flow (that coming from pipes upstream if any, and the Pit Top Flow). This calculation may inform that the PitTop flow is in fact limited to something less than that calculated by the PitTop. It is important to do this check as this is the flow that needs to be removed from the 2D model, and also to ensure Volumetric accounting is accurate. That is, no water is lost, because of differences in Pipe & Pit capacities! So to Summarise there are three pieces of information required and a further check:
|
When using the dynamic solver, a SWMM node is a storage. All the flows that enter a node(from pipes, user inflow, catchment, etc.) are added to/subtracted from the amount of water stored in the node. This in turn changes the water surface elevation in the node. The latter is used to calculate the flow in the pipes connected to the node at the next time step. Now, the added interchange code can add or remove quite a bit of mass from one time-step to another, which in turn could induce oscillations. Some techniques are implemented in the code to limit the potential instabilities. See especially the In my PhD thesis there are more details on how this was implemented in Itzï, and the influence of those techniques on the coupled model stability. The sections of interest are 2.2 and 3.2. |
|
Hi all, just a desperate Plea for a Status Update ?? |
|
the feature "as-is" is already sitting in the Does this make sense? |
|
I'm particularly interesting in @dickinsonre's thoughts on this as well |
|
Ok... is there any where a small example of how it is to operate ? Once I can determine how this is done I'd be very happy to set up various tests.... |
|
I will comment on this, Rudy, later in the week. It might take me all werk @RudyFrom3 due to just getting back to my normal work schedule after a long month of traveling |
|
@bemcdonnell what would be the requirements to have the feature2dflood branch merged into dev? Right now, I see this:
Is the OWA core team open to have such a feature included in the main branch? |
|
@lrntct and @bemcdonnell my understanding from a recent conversation I had with @LRossman is that he is working on a feature that may complement the work proposed here. |
|
The feature that I am working on is to add storm drain inlet analysis to SWMM. It computes the amount of surface flow captured by street inlet structures (grates and curb openings) and sent into a below ground sewer system using the FHWA HEC-22 methodology. HEC-22 is the de facto standard used in the US for analyzing street drainage systems, referred to in numerous state and local agency design manuals.
HEC-22 uses different sets of equations to compute capture efficiency depending on whether an inlet is located on grade or on sag. Similar to feature2dflood there is no need to explicitly represent the transfer between the surface (major) system and sub-surface (minor) system with an orifice or weir element. Once the amount of flow captured by the inlet is computed it is directly transferred between the two systems. Below is the single additional function that accomplishes this for Dynamic Wave analysis, called for each link after new flows have been found and before new node depths are computed: Similar code exists for inlet analysis under Steady Flow and Kinematic Wave routing. There is also the option to send the captured flow onto a subcatchment which could contain an LID control. All of the HEC-22 calculations are made in a new code module named This feature is purely optional and doesn't interfere with any of SWMM's normal calculations if it is not deployed. I expect to have a completed version of it by the end of the month and will be happy to share it with OWA-SWMM. |
|
@LRossman Thanks for the update! |
|
@LRossman that's pretty impressive actually. Thanks (in advance) for making those updates! |
|
@LRossman
We all thank you so mutch!
A sexta, 18/09/2020, 19:06, Lew Rossman <[email protected]> escreveu:
… The feature that I am working on is to add storm drain inlet analysis to
SWMM. It computes the amount of surface flow captured by street inlet
structures (grates and curb openings) and sent into a below ground sewer
system using the FHWA HEC-22 methodology. HEC-22 is the de facto standard
used in the US for analyzing street drainage systems, referred to in
numerous state and local agency design manuals.
[image: image]
<https://user-images.githubusercontent.com/12769926/93627613-33199c00-f9b3-11ea-9482-0c91515b64c9.png>
HEC-22 uses different sets of equations to compute capture efficiency
depending on whether an inlet is located on grade or on sag. Similar to
feature2dflood there is no need to explicitly represent the transfer
between the surface (major) system and sub-surface (minor) system with an
orifice or weir element. Once the amount of flow captured by the inlet is
computed it is directly transferred between the two systems. Below is the
single additional function that accomplishes this for Dynamic Wave
analysis, called for each link after new flows have been found and before
new node depths are computed:
void redirectInletFlows(int i)
//
// Input: i = link index
// Output: none
// Purpose: removes flow captured by an inlet placed in link i and adds
// it to the inlet's designated receptor node.
//
{
int j, m;
double qc;
// --- check that link has an inlet receptor node
m = inlet_getReceptorNode(i);
if (m < 0) return;
// --- find flow captured by the inlet
qc = inlet_getCapturedFlow(i);
// --- find which end of link to remove flow from
if (Link[i].newFlow >= 0.0)
j = Link[i].node2;
else
j = Link[i].node1;
// --- remove flow from link's end node and add it to receptor node
Node[j].inflow -= qc;
Node[m].inflow += qc;
}
Similar code exists for inlet analysis under Steady Flow and Kinematic
Wave routing. There is also the option to send the captured flow onto a
subcatchment which could contain an LID control. All of the HEC-22
calculations are made in a new code module named inlet.c.
This feature is purely optional and doesn't interfere with any of SWMM's
normal calculations if it is not deployed. I expect to have a completed
version of it by the end of the month and will be happy to share it with
OWA-SWMM.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKMCJQTKBS3EOJNO4PU2XRTSGOOQRANCNFSM4EGT2CBQ>
.
|
|
This is fantastic Lew and helpful to so many people. I have a few questions - what happens if the sub surface pipe system is full and there is surcharge? Does the inlet flow reverse and flow goes into the street? |
|
@dickinsonre yes, that's the idea although I haven't implemented it yet. I will probably use the on sag HEC-22 equations for this, even for on grade inlets, as they are orifice/weir based. It will also require that the program adjust the rim elevations of the receptor sewer nodes so they equal the elevation of the top of the street curb they receive captured flow from. Once implemented, the I forgot to mention that another feature being added is a re-usable Street Cross Section object that makes it easier to set up a surface street network. The shape and its parameters are shown below and the program automatically computes an internally used transect with the relevant geometric properties for it.
|
|
@LRossman That's neat! It is a different approach than the solution proposed here, but they could share some code? |
|
@lrntct it seems it would be awkward to share code between the two types of flow exchange applications. One major difference is that the HEC-22 inlets are placed in street conduits, not at the street junction nodes. And there can be more than one inlet per street and a different number per each side of the street (they get evaluated sequentially for on grade conditions). There are two new data structures defined in |
|
Hi All, The ANUGA team has now got a number of ANU Students assisting with Coding... The Students have got working code, but are struggling to get access to the correct Paramters to ensure their volumetric check is correct. Can anyone please List the complete volumetric check at the NODES... Thank you |
|
If they are reading the code then HOW node depths, node areas, and flooded volume is calculated is shown in the function setNodeDepth in the SWMM5 Code. If you want to see the overall volume check have them read the SWMM5 hydraulics reference manual or looks at the code in statsrpt.c. Please remember, the flooded loss is different with the Extran and Slot options and surface or non surface ponding. The slot option is a cleaner solution for 2D connections, IMO. |
|
Hi all, we are the ANUGA team from ANU. Currently, we have implemented a method to couple ANUGA and PySWMM. However, we have some confusions about some parameters in PySWMM. In addition, we have some confusions about the total_inflow and total_outflow at each node. From my understanding, the total_inflow is the inflow rate at a node and total_outflow is the outflow rate at a node that both units of them are volume per time step. We would be grateful if you could help us check our understanding. In addition, we found that the total_outflow at an outfall type of node is always 0. We are confusing about why the total_outflow at the node with outfall type cannot be obtained. Furthermore, we found that the water loss we aim to calculate is related to the loss of SWMM and we would like to compare the two losses. According to the SWMM system, we found that there is a parameter in PySWMM called flow_routing_error which indicates the water loss during the whole simulation process. However, the flow_routing_error is always 0 when we would like to call it and print it. Thank you in advance. We appreciate any suggestions. |
|
But, there are two parameters related to the water in a conduit, "flow" and "volume" - flow in SWMM5 is the solution to the St Venant 1D equation based on the hydraulic characteristics at the ends of the links. The hydraulic characteristics are based on the depth at the upstream and downstream ends of the link. The volume is based on depth. Volume is not the same as flow. For example, you can have a full pipe with no flow if the HGL is flat or there is a backwater condition to the pipe. There is one flow per link but three depths. |
|
Storage nodes have a volume of water at each time step so "water at each node" is important. How is knowing the total volume of the network at each time step helping your computer flooding loss? |
So when there is a backwater in a pipe, the flow may be 0 as it is offset by the backwater? And whether it means the volume is calculated by the average depth of water in the link? Volume is the total water volume in that link in a specific time step? |
From our consideration, the total volume of the network at each time can give us the total volume which is not on the ANUGA domain. As the water will be pass to the network from ANUGA domain when coupling in each time step, the water passed into the network will be eliminated from the ANUGA domain. Therefore, we believe the water remained on the ANUGA domain and water in the network is the total water in a specific time. So when can we use the value to compare with the expected volume (a constant input volume * simulation duration) to get how much water will be lost during simulation. Actually, if we can only compare the water volume at the end of simulation, that's acceptable as well. We would like to check whether our hypothesis |
|
The volume in a link is Link[j].newVolume = aMid * link_getLength(j) * barrels; where aMid is the cross-sectional area of the link based on the Midpoint depth. The Midpoint depth is the average of the upstream and downstream depths in the link. Barrels are just the number of the same links with the same hydraulic characteristics between the same two nodes. It is normally one. Length is the length of the link - some links are lengthened if the pipe is short and the user selects that option. So volume is related to flow but you cannot just take flow and get the link volume. Flow is the solution - volume is a calculated value. It changes every time step and is calculated at every iteration. |
|
the total volume of the network at each time == the total volume at each time is also affected by the inflows to the nodes, and outflows from the outfalls - you seem to have one inflow and no outfalls so maybe this is not a concern now of yours but should be a concern in the future. |
|
From My Perspective in terms of functionality:
|
|
Comments in Quotes • At the start of a simulation both are Dry, As rainfall starts initially the ANUGA Domain is wet, and runoff starts to build and flow toward the NODE locations. “What about the 1D network? Is that dry at the start as well?” |
|
• At the start of a simulation both are Dry, As rainfall starts initially the ANUGA Domain is wet, and runoff starts to build and flow toward the NODE locations. • The depth of water at the NODE locations determines the Potential inflow, • The flow starts to fill the Node (Pit) and drive Flow into the PIpe Segment • As the flow increases at some point the inflow Potential (Driven by the depth) into the Pit may exceed the Pipe Capacity, hence some of the inflow as determined by the driving depth cannot be accepted. • When the rain stops and runoff reduces, eventually the overland flow stops, and sometime after that the remaining volume in the pipe network drains out... leaving both essentially dry... “Okay” • The volumetric check is important to ensure the total mass at every time step is fully accounted for ensuring a totally mathematical stable simulation... |
|
Comment on this note of yours " Depth is determined from Elevations (Elevation of Water, Ground, and Invert}" For example, say the rim elevation of the node is 100 meters, the invert of the node is 90 meters but the centroid of your ANGUA mesh cell is at 80 meters - the depth of water on the mesh would have to reach 20 meters for you to have any inflow from the mesh to the 1D network. Another example, say the mesh centroid is at 110 meters then if you use only depths the flooded water can leave the node rim to the mesh as soon as there is a flooded depth - since the mesh has zero depth. I guess i just don't understand how using depth is correct. I am probably not even understanding your approach to using depths. Now reading https://www.wikiwand.com/en/ANUGA_Hydro and other documentation. I see you have a Github location 2017/05/20: Github Branch created to initiate the development of SWMMLINK 1D Pipe network to ANUGA 2D Dr. Ole Nielsen, Assoc. Prof. Stephen Roberts, Rudy Van Drie, Dr. Petar Milevski past swmm5 discussion which helps (me) https://www.openswmm.org/Topic/9964/how-to-surcharge-swmm-into-a-2d-domain this helps as well |
|
Thank you for directing to those resources... The coding in ANUGA to date has been very strict in terms of its accurate accounting for volume... the SWMM LINK needs to ensure an equivalent level of robustness... |
|
I am really Struggling to Understand why it appears so difficult to talk to SWMM and extract something as simple as the Volume ? If we can track the Volume in ANUGA at every time step, we need to ensure that the SWMM doesnt Create or Loose any Volume? Currently Students working on this are finding a Volume Loss in SWMM.... which may be a reporting problem... or a real problem ?? This issue needs to be understood and fully identified before moving forward... Can any one please provide insight ? What happened to the SWMM LID TOP idea, to calculate the inflow through a Grate or a Lintel ?? |
|
@RudyFrom3 I believe you can use the I wonder if the reason your team is seeing a volume loss is because they are relying on the results displayed at each reporting time step and ignoring results at intermediate steps which are not reported. Finally, if by "the SWMM LID TOP idea, to calculate the inflow through a Grate or a Lintel" you mean the comment I posted to this thread on 9/18/2020, it has been incorporated into a soon to be released version of EPA SWMM (not PySwmm). You can view a slide presentation about it here. |
|
Great!
Thanks for sharing!
Cumprimentos,
*Valter Albino -* Geógrafo Físico, M.Sc.
Modelação H&H / Riscos ambientais / OT&U
www.valteralbino.wixsite.com/hydrodynamics
Lew Rossman ***@***.***> escreveu no dia quarta, 21/04/2021
à(s) 18:50:
… @RudyFrom3 <https://github.com/RudyFrom3> I believe you can use the SystemStats
class in PySwmm to get the components of the system flow balance
(including the system volume contained in the member named final_storage)
at each time step of a simulation. Please see this link
<https://pyswmm.readthedocs.io/en/latest/reference/system.html>.
I wonder if the reason your team is seeing a volume loss is because they
are relying on the results displayed at each reporting time step and
ignoring results at intermediate steps which are not reported.
Finally, if by "the SWMM LID TOP idea, to calculate the inflow through a
Grate or a Lintel" you mean the comment I posted to this thread on
9/18/2020, it has been incorporated into a soon to be released version of
EPA SWMM (not PySwmm). You can view a slide presentation about it here
<https://www.icwmm.org/files/2021-C030-05.pdf>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKMCJQTVGDL7MXVXF76ZB7LTJ4F5TANCNFSM4EGT2CBQ>
.
|
|
SWMM5 is a link/node system in which the area of the node is found from the width times 1/2 length of the connecting links (if there are no offsets between node and link). I hope you are not getting the volume from the node area? I t should be the volume in the links plus the actual volume of the nodes if you want to compare it to your 2D network. Can you make a time series to show the following:
|
|
Hi all, we have found the issues about water loss, it is attributed to the flooding loss when node.depth excesses the maximum depth + surcharge_depth at a node. And I found the flooding can be gotten by nodes.flooding. However, the unit of flooding seems always cubic feet even why have set the unit as cubic meters in SWMM. In other words, such as the unit of links.volume is cubic meters, the unit of nodes.flooding is still cubic feet. |
Some recent discussions on the OpenSWMM mailing list shows that there is some interest in linking SWMM to a 2D surface domain.
This as been done by some commercial packages, and by researchers as well [1, 2].
I achieved this in Itzï by using Cython, but it could be much cleaner (and possibly faster) if this computation is done directly in the SWMM model.
I believe this would be a nice addition to SWMM. I have an adea on how it could be implemented. I'll detail it is subsequent posts.
See related issues:
#110
[1] Seyoum, Solomon Dagnachew, Zoran Vojinovic, Roland K Price, and Sutat Weesakul. 2012. “Coupled 1D and Noninertia 2D Flood Inundation Model for Simulation of Urban Flooding.” Journal of Hydraulic Engineering 138 (1). American Society of Civil Engineers:23–34.
[2] Leandro, J., and R. Martins. 2016. “A Methodology for Linking 2D Overland Flow Models with the Sewer Network Model SWMM 5.1 Based on Dynamic Link Libraries.” Water Science and Technology 73 (12):3017–26. https://doi.org/10.2166/wst.2016.171.
The text was updated successfully, but these errors were encountered: