search

pyswmm / Stormwater-Management-Model

PySWMM Stormwater Management Model repository
Other
99 stars 77 forks source link

Calculate the flow from/to a surface model #111

Open lrntct opened 6 years ago

lrntct commented 6 years ago

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.

rudyvandrie commented 4 years ago

Hi all.... here we are in 2020 (sounds almost mystical) any way with little meaningful progress in Linking SWMM to ANUGA as yet... I am hoping to get this moving once again some how ? Even if any one may know of a coder that may be interested in being paid? For this really is the holy grail for Urban Flood modelling, with a pipe network capability ANUGA will continue to be largely ignored for Urban Flood analysis. @lrntct How does Itzi handle the difference in time steps in the two models ? This seems to be a significant stumbling block?

dickinsonre commented 4 years ago

How much are you willing to pay, Rudy? Is it 1000, 10,000, 100,000+ USD dollars? I will mention that there are at least 3 vendors in Australia that have linked 1D to 2D models and you can buy their software. My company makes 5 products with 1D to 2D connections, BTW @Innovyze and the cost is based on years of development.

rudyvandrie commented 4 years ago

Well... good question.... ANUGA is a Free and open source project, just in the throws of being converted from Python 2.x to Python 3.x, the lack of pipe network capability is in general not a huge dilemma (for severe flood events) as it does have capacity to model Culverts & Bridges. However in order to model urban flooding and specifically in events where the pipe network carries a substantial proportion of flow, it becomes critical. Hence linking to a well known code such as SWMM is particularly appealing. Noting that ANUGA does have a 1D SWW solver that has been partially developed. Several users have suggested that funds could be raised to code up this crucial link....

lrntct commented 4 years ago

How does Itzi handle the difference in time steps in the two models ? This seems to be a significant stumbling block?

To maintain coherence between the models, Itzï reduces the time step of the surface model to match. The details could be seen in simulation.py

bemcdonnell commented 4 years ago

@rudyvandrie and @lrntct, if you are interested, we could revive this old pull request which allows you to stride forward by setting the number of seconds you want to advance your SWMM simulation.

rudyvandrie commented 4 years ago

That sounds like it could be useful I think ?

RudyFrom3 commented 4 years ago

@bemcdonnell yes please retrieve the old pull request for.... stride....

Regards Rudy

rudyvandrie commented 4 years ago

Hi all, Ive put this comment in issue #134 but it is more relevant here: Ole Nielsen (previous Co-author of the ANUGA model) is considering trying to crowd fund the ongoing development of the required Linking object between PySwmm and ANUGA. If this is done in a generic way I would guess it would more easily allow linking any other surface model to Pyswmm also.

@bemcdonnell I have not noticed a response to your previous suggestion... Re: Pull request for Stride ?

rudyvandrie commented 4 years ago

@lrntct I have noticed that code development at: lrntct /pyswmm

has not progressed for quite a while (2 years ?) is the project still being pursued ?

The ANUGA camp has ground to a halt with difficulties in getting examples of application and unit tests of the linking concepts. Both models need to have super accurate volumetric accounting at every node where there is any exchange of flow, else there is the likely outcome missing or added false volume? Hence the desire to raise crowd funding ideas as above?

bemcdonnell commented 4 years ago

@rudyvandrie, like many open source projects, this project gets feature enhancements when people show up and add the features that they need. I personally do not need the stride step in my workflow therefore I will probably not being implementing it any time soon. However, I think it will be a very useful contribution! I suggest you revive the pull request (or just copy the changes and integrate them into a new pull request). I'm pretty sure this functionality is only just a few lines of code in the swmm.c code:

https://github.com/OpenWaterAnalytics/Stormwater-Management-Model/blob/41b555cc9f40525c71a07936e8726306658e3462/src/swmm5.c

Can you work on getting this integrated?

rudyvandrie commented 4 years ago

I personally am quite a poor coder (limited to Python really..) but can have a look, and maybe get a skilled coder to assist ?

lrntct commented 4 years ago

IMTA got a project approved this year that includes the goal of getting the coupling code included in OWA SWMM main branch. It's unlikely I'll have time to work on it myself, but I hope to see progress this year on that topic.

bemcdonnell commented 4 years ago

@rudyvandrie, what is your schedule for getting this feature into production?

rudyvandrie commented 4 years ago

Well Optimally ASAP... but we have been discussing this quite a while, and progress has halted (I wish I was a better coder... but Im not) But apparently from what has been said in this forum... its sooo close.... that if I knew a coder I would pay to have it done.

bemcdonnell commented 4 years ago

@rudyvandrie, please send me an email directly bemcdonnell(at)gmail.com

lrntct commented 4 years ago

A colleague of mine is working on the boost tests for the coupling functions. I hope we could have a PR in the coming weeks. Our next step would be to implement those functions in pyswmm. What would be the next steps for a merge in the main branch of OWA SWMM?

lrntct commented 4 years ago

@lrntct I have noticed that code development at: lrntct /pyswmm has not progressed for quite a while (2 years ?) is the project still being pursued ?

I've worked on that while I was developing the C coupling code, because it was easier for me to test. When we are closer to getting the C coupling code approved into master, we could go back on the python interface and conclude the coupling integration. IFAIR, there was little missing. pyswmm has moved on since then, so merging the new code into the old branch and writting the tests might be the most difficult parts.

lrntct commented 4 years ago

@dickinsonre I see that in in 5.1.013 there have been some changes to the behaviour of the surcharged nodes (and addition to Preissman slot, if I understand well). Do you know if this could change how nodes overflows and how?

dickinsonre commented 4 years ago

@lrntct the current version of SWMM is actually 5.1.014 but the later version has only a few bug fixes not associated with flooding. The slot was added in SWMM 5.1.013 and changes the way the HGL and flows are calculated when a node is surcharged. The ability to have a surcharge depth was also added to storage nodes in SWMM 5.1.013. The code for ponding and the so important parameter fullldepth was also changed.

    // --- closed storage units that are full are in surcharge
    else if (Node[i].type == STORAGE)
    {
        isSurcharged = (Node[i].surDepth > 0.0 &&
                        yLast > Node[i].fullDepth);
lrntct commented 4 years ago

@dickinsonre Thanks. Do you know if there is a comparison somewhere that shows how the nodes behave while surcharged in both versions?

michelleannesimon commented 4 years ago

An excellent way to see differences between SWMM versions is to go to openswmm.org code viewer comparison, such as https://www.openswmm.org/Compare?v1=SWMM51014&v2=SWMM51013

dickinsonre commented 4 years ago

@michelleannesimon Thanks, in addition, there have been quite a few papers by Jose Vasconcelos - Auburn and others at the ICSWMM conferences comparing the slot to the Extran option (Extran 3) option and monitored geyser data.

lrntct commented 3 years ago

@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?

michaeltryby commented 3 years ago

@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.

LRossman commented 3 years ago

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

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.

michaeltryby commented 3 years ago

@LRossman Thanks for the update!

bemcdonnell commented 3 years ago

@LRossman that's pretty impressive actually. Thanks (in advance) for making those updates!

valterhydrodynamics commented 3 years ago

@LRossman We all thank you so mutch!

A sexta, 18/09/2020, 19:06, Lew Rossman notifications@github.com 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 https://github.com/OpenWaterAnalytics/Stormwater-Management-Model/issues/111#issuecomment-695009690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKMCJQTKBS3EOJNO4PU2XRTSGOOQRANCNFSM4EGT2CBQ .

dickinsonre commented 3 years ago

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?

LRossman commented 3 years ago

@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 inlet_getCapturedFlow() function in the code listed above will simply be returning a negative value.

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.

Street_xsect6

lrntct commented 3 years ago

@LRossman That's neat! It is a different approach than the solution proposed here, but they could share some code? For instance optionally using a HEC22 inlet formula instead of weir/orifice equation for the flow interchange with an external model?

LRossman commented 3 years ago

@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 inlet.h that hold information about inlets. The TInletDesignstruct contains information on a particular inlet's design (inlet type and its dimensions). The collection of a project's available designs are stored in a InletDesignarray. The TInletUsagestruct indicates which inlet design a street conduit should use, how many inlets to use, where to send the captured flow, and to what degree the inlet is clogged. The only linkage between these new inlet-related objects and SWMM's original data structures is through a new property added to the TLinkstruct, named inletwhich is a pointer to a TInletUsagestruct. It's not apparent to me how these data structures could be shared with flow exchanges to an external 2-D surface model. Perhaps you can see an opportunity (or it might be easier to look for it after the source code is posted).

RudyFrom3 commented 3 years ago

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

dickinsonre commented 3 years ago

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.

Chen-Huang-326 commented 3 years ago

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. As we try to calculate the water loss in each time step during a flooding simulation, we basically use the real water volume minus expected water volume in each time step. The expected water volume is the water we pour into the ANUGA domain which is used for simulation (a constant input water with velocity 0.25 m3/s, so the total expected water volume = 0.25 m3/s * t). And the real water volume is the water on the ground (we can use a method to get all water on ANUGA domain) plus the water in the SWMM pipe system. However, we are not sure which PySWMM parameters should be involved. We would be grateful if you have any suggestions about what parameters should be involved to calculate the water in the pipe system. From my perspective, the water in the pipe system should be the combination of the water in the conduits. But, there are two parameters related to the water in a conduit, "flow" and "volume". I would like to confirm the difference between these two parameters. Or, perhaps there are any additional water should be considered, such as the water at each node?

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.

dickinsonre commented 3 years ago

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.

dickinsonre commented 3 years ago

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?

Chen-Huang-326 commented 3 years ago

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.

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?

Chen-Huang-326 commented 3 years ago

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?

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 is manipulatable.

dickinsonre commented 3 years ago

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.

dickinsonre commented 3 years ago

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.

RudyFrom3 commented 3 years ago

From My Perspective in terms of functionality:

dickinsonre commented 3 years ago

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?” • The depth of water at the NODE locations determines the Potential inflow, “The depth above the Rim Elevation of the node? What happens if you have bad DEM data and the ANUGA grid is below or above the Rim Elevation of the Node?” • The flow starts to fill the Node (Pit) and drive Flow into the PIpe Segment “The flow in the pipe is based on the depth of water in the node above the Invert of the node – the invert of the pipe matters as well if there is a pipe offset from the node invert. Should you not use Elevation instead of depth to drive the flow into ou out of the node?” • 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. “The pipe capacity does not matter – the solution of SWMM5 is a 1D St Venant iterative solution based on the HGL at both ends of the link. The HGL is often related to the nide HGL but not always if there is an offset in the link.” • 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... “In SWMM5 there is overall network volume check and a node-by-node volume check. You need to check the 1D to 2D node continuity as well. You could have an overall good balance but a bad balance at certain nodes.”

RudyFrom3 commented 3 years ago

• 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?” {The assumption is prior to Any Rainfall unless there is back water and a water source down stream (River Lake Tide, the Piped System is Dry...}

• The depth of water at the NODE locations determines the Potential inflow, “The depth above the Rim Elevation of the node? What happens if you have bad DEM data and the ANUGA grid is below or above the Rim Elevation of the Node?” {There are ways to easily check this and adjust this so this is not the case..}

• The flow starts to fill the Node (Pit) and drive Flow into the PIpe Segment “The flow in the pipe is based on the depth of water in the node above the Invert of the node – the invert of the pipe matters as well if there is a pipe offset from the node invert. Should you not use Elevation instead of depth to drive the flow into ou out of the node?” Depth is determined from Elevations (Elevation of Water, Ground, and Invert}

• 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. “The pipe capacity does not matter – the solution of SWMM5 is a 1D St Venant iterative solution based on the HGL at both ends of the link. The HGL is often related to the nide HGL but not always if there is an offset in the link.” {If this is the case you are saying that SWMM accounts for the pipe capacity being less than pit capacity automatically ?}

• 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... “In SWMM5 there is overall network volume check and a node-by-node volume check. You need to check the 1D to 2D node continuity as well. You could have an overall good balance but a bad balance at certain nodes. {The mass continuity in ANUGA is cell to cell not overall.... hence for example the current Culvert Routines in ANUGA have full mass accounting for inflow and outflow at every time step...}

dickinsonre commented 3 years ago

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

https://github.com/GeoscienceAustralia/anuga_core

https://iwaponline.com/wst/article/73/12/3017/20354/A-methodology-for-linking-2D-overland-flow-models

RudyFrom3 commented 3 years ago

Thank you for directing to those resources... ANUGA has conserved quantities of Momentum X & Y and Stage (Water Level Elevation) and Ground Elevation, ANUGA does not know about depth. However in needing to calculate an inflow capacity in a INLET PIT or a CULVERT headwall, DEPTH is required. Hence various OPERATORS in ANUGA determine DEPTH and report on depth for these calculations. For the SWMM LINK project I assume a similar process as currently occurs in the CULVERT OPERATORS would occur, where depth is calculated to determine the Inflow Capacity. ANUGA has available to it several methods by which the terrain can be forced to match PIT LIP Levels... so differences in terrain in the 2D domain and the PIT level are not so much an issue...

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...

RudyFrom3 commented 3 years ago

I am really Struggling to Understand why it appears so difficult to talk to SWMM and extract something as simple as the Volume ? What is the Volume in the System ? Should it not simply be the Summation of the Link(s) Volume and Node(s) 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 ??

LRossman commented 3 years ago

@RudyFrom3 I believe you can use the SystemStatsclass 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.

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.

valterhydrodynamics commented 3 years ago

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 https://github.com/OpenWaterAnalytics/Stormwater-Management-Model/issues/111#issuecomment-824245080, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKMCJQTVGDL7MXVXF76ZB7LTJ4F5TANCNFSM4EGT2CBQ .

dickinsonre commented 3 years ago

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:

  1. Volume in ANGUA, 2. Volume in SWMM5, 3. Inflow Volume from the 2D 4. Outflow volume from the 1D for each time step so at least others can see a numerical value for your volume questions. In general, does ANGUA lose volume over the time step? Evaporation, infiltration, or loss through a boundary?