pyswmm
pyswmm copied to clipboard
pyswmm
Dynamically Calculated Pit Energy Loss Coefficients
In 1980 Clive Hare wrote his thesis that culminated in an approach to calculate the Loss Coefficients for Nodes (Pits) in a pipe network model. It utilises the flow in each pipe (LINK) and the flow rate entering the pit from the surface and also accounts for the angle of incoming pipes (LINKS) to determine the Loss Coefficient. In this way the loss coefficient can be update at each time step to accurately vary the losses based on the dynamic behaviour of the piped network.
I can imagine that the best way to include this in the swmm model is directly in its code ? This is reliant on also knowing the flow rate into the pit from the surface, which requires at least a rating curve attached to a pit, which is currently also not a direct capability of SWMM. Hence an alternate approach is to code these items in PySWMM. That is code a rating curve for the inflow into a pit... and code the dynamic changing of the loss coefficients in PySWMM ??? Would be happy to discuss this further with a view to bringing it to fruition.
Here are reference papers to the method initially described by Hare... (Full Thesis is 10Mb..) But I would think that coding it would not be particularly difficult? However does require the Flow into the pit from the surface to be identiified hence requires at least a Rating Curve, or perhaps a combined, Weir/Orifice Type Equation allocated to a Node ??
Drains_PIT_Losses.pdf Pit_Losses_paper1.pdf 01Hare-Front.pdf
@RudyFrom3, I think we should have this discussion start in the SWMM repo: https://github.com/OpenWaterAnalytics/Stormwater-Management-Model. If there is a cleaner implementation directly in the engine, it would seem like a path of least resistance. Do you mind raising the issue there first?
I will just comment that using Python to calculate engine parameters will make the model probably take weeks to run? At each and every iteration of a time step for each link you will have to pass information to the Python code, do the Hare calculations, pass the result back to SWMM5 and then proceed onwards to another stopping point to wait for Python. i cannot imagine how this would work with multi cores as well.
BTW, the flow into the Pit or Inlet from the surface is called Lateral Inflow and is already known.
When linking to a 2D code like ANUGA the swmm time step will be considerably larger than the ANUGA time step so potentially it may not be such a burden, however it would be the aim to eventual code it directly in swmm in C I would think. The point is to dynamically allocate variable values of loss coefficients. With regard to the Lateral Inflow.... I think the difference is that this does at the moment not account for the throttled inflow capacity of a grate and inlet opening ??
I may not be completely understanding your idea Rudy but you should not have different solutions at each time step / time step iteration and the connection time to your 2D ANGUA model. The model solution will be horribly unstable. The engine would be using one solution for 5 minutes and another at the 5 minute interval, for example, or whatever time you want to connect to the 2D engine.
The only way to do this using your 2D time step would be to calculate the loss and then use a constant loss until the next time to connect to ANGUA.
Lateral flow is runoff, rdii flow, dry weather flow, baseline flow and time series inflow at the node, pip, inlet, manhole etc.
Yes ANUGA uses adaptive time step as it captures shocks so usually sub second. SWMM will use much larger time steps. The idea is is that ANUGA will pass Depth to SWMM over a inlet Pit, some (new) code in SWMM will calculate the flow into the pit, confirm it can be accepted into the pipe system. Update the losses and calculate pipe system dynamics including any surcharge or outflow back to the 2D domain. Flow is passed back to ANUGA. Then next time step in SWMM is processed. So ANUGA will average flow over its time steps till the next SWMM time step... We already have code that will track volume out and back into ANUGA....
The new code I imagine will be an inlet routine for a node (or more accurately possibly a {small} storage) to transform depth over pit to flow into pit. Adjusted for pipe capacity and losses in the pit ?
My final (hopefully) comment on this topic is that you need a new SWMM5 solution to properly implement these admittedly nice ideas. A Link/Node network with the depth of the node a function of the surface area of the connecting links is step too far. See also Ming Jin's comments on the SWMM List server as well about SewerGems.
I opened an issue in the SWMM tracker for the inclusion of a surface/sewer coupling code inside SWMM, and the ideas I have about the implementation. I already did something similar in Itzï. I believe that implementing it in SWMM would make it much cleaner.
This topic is obviously complex and inter-related to several topics when discussing links to a 2D surface model. However i feel there is real benefits in being able to dynamically adjust energy loss parameters based on comparative flows in various pipes and the inflow from the surface inlet pit. https://github.com/OpenWaterAnalytics/Stormwater-Management-Model/pull/124 is now closed... but i m wondering if it includes a check of downstream pipe capacity to limit the flow from the surface inlet pit ??
I believe any computation should be done in the SWMM code base. Then pyswmm will provide an interface.See there for relevant discussion on the matter.
I modified the pyswmm code to match the changes made to SWMM for surface coupling. Unfortunately, I haven't had much time to work on that matter since last December (8 months already!). I still plan to continue the development, but things have been hectic lately on the personal side. My changes are there. I can create a PR if a maintainer think it is the right ting to do.
Hi all, 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.
@rudyvandrie just wanted to circle back on this conversation. Are you still interested in working on the integration?
Absolutely....
Regards Rudy
On Thu, 18 Aug 2022, 18:33 Abhiram, @.***> wrote:
@rudyvandrie https://github.com/rudyvandrie just wanted to circle back on this conversation. Are you still interested in working on the integration?
— Reply to this email directly, view it on GitHub https://github.com/OpenWaterAnalytics/pyswmm/issues/134#issuecomment-1219326084, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE26T4NTYQP7DJ5RNC6FTHLVZYGQNANCNFSM4EGQEHVA . You are receiving this because you were mentioned.Message ID: @.***>
@rudyvandrie awesome, please fo let me know if you anything from our end to get this going :)