OpenWaterAnalytics
Emitter flows can be negative if node pressure is negative
I think the only thing that is unexpected (or possibly a bug) is that the engine does not produce the usual warning message described in the user's manual:
EPANET will issue a warning message when it encounters negative pressures at junctions that have positive demands. This usually indicates that there is some problem with the way the network has been designed or operated. Negative pressures can occur when portions of the network can only receive water through links that have been closed off. In such cases an additional warning message about the network being disconnected is also issued.
Under normal circumstances, negative pressures would be considered a modeling error. There may be reasons to ignore negative pressures for junctions without demand where elevation is not known or irrelevant. However EPANET's position toward negative demands created in emitters is ambiguous.
Any other perspectives on this @LRossman @jamesuber @eladsal ?
In terms of a use-case, I guess that someone using a pressure-driven demand model to investigate low pressures during an emergency event could be very concerned about negative pressures at the emitters and might even consider them credible. Probably less the case for negative pressures at junctions where the demands were specified externally.
But still, the reference text you cited would seem to apply equally well to emitter junctions, especially the intent to warn the user about “some problem with the way the network has been designed or operated.” So if there were a vote, I’d come down on the side of uniform warning.
Jim Uber, Ph.D. Water Network Optimization Xylem Decision Intelligence Solutions M: 513.368.6303 [signature_785061632]
From: Sam Hatchett @.> Date: Monday, November 15, 2021 at 9:24 AM To: OpenWaterAnalytics/EPANET @.> Cc: Uber, James - Xylem @.>, Mention @.> Subject: Re: [OpenWaterAnalytics/EPANET] Emitter flows can be negative if node pressure is negative (Issue #659)
I think the only thing that is unexpected (or possibly a bug) is that the engine does not produce the usual warning message described in the user's manual:
EPANET will issue a warning message when it encounters negative pressures at junctions that have positive demands. This usually indicates that there is some problem with the way the network has been designed or operated. Negative pressures can occur when portions of the network can only receive water through links that have been closed off. In such cases an additional warning message about the network being disconnected is also issued.
Under normal circumstances, negative pressures would be considered a modeling error. There may be reasons to ignore negative pressures for junctions without demand where elevation is not known or irrelevant. However EPANET's position toward negative demands created in emitters is ambiguous.
Any other perspectives on this @LRossmanhttps://urldefense.com/v3/__https:/github.com/LRossman__;!!OKzgfr8!IBlgBvI3FRZaS5NPkO94q56YFbJAXZnXS3HX2wL8D2UMOcp9j-yUHemd2FO-txdvuxw$ @jamesuberhttps://urldefense.com/v3/__https:/github.com/jamesuber__;!!OKzgfr8!IBlgBvI3FRZaS5NPkO94q56YFbJAXZnXS3HX2wL8D2UMOcp9j-yUHemd2FO-4GpDoHk$ @eladsalhttps://urldefense.com/v3/__https:/github.com/eladsal__;!!OKzgfr8!IBlgBvI3FRZaS5NPkO94q56YFbJAXZnXS3HX2wL8D2UMOcp9j-yUHemd2FO-igR14Bo$ ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/OpenWaterAnalytics/EPANET/issues/659*issuecomment-968960851__;Iw!!OKzgfr8!IBlgBvI3FRZaS5NPkO94q56YFbJAXZnXS3HX2wL8D2UMOcp9j-yUHemd2FO-vYtuU5c$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AASMACNBFTEWGHDCK6QMA6TUMEJ2DANCNFSM5IBEKARQ__;!!OKzgfr8!IBlgBvI3FRZaS5NPkO94q56YFbJAXZnXS3HX2wL8D2UMOcp9j-yUHemd2FO-g9-tIuE$.
There was no negative pressure warning because the emitter node has negative demand and acted as a source. Can the emitter be limited to 0 when the emitter flow becomes negative?
A couple of things here. First, placing an emitter at a node with negative demand is kind of weird (so the node is expected to have both inflow and outflow :confused:). And it's not uncommon to have a negative pressure for a negative demand node when its elevation is below the nodes it connects to.
Second, allowing negative flow (i.e. inflow rather than outflow) through an emitter has been identified as an issue previously. Using the common definition of an emitter as a device that discharges to the atmosphere (as in a sprinkler head) then a negative flow through it should not be allowed. The code would need to be modified to do this, using the same method that sets pressure-dependent demand flow to 0 when the pressure drops below the prescribed minimum value. This would break backwards compatibility but it's probably worth doing.
Finally, I've been collaborating with Ezio Todini and his colleagues on evaluating alternative PDA methods. As a result, I've found some modifications to v.2.2's PDA routine that will improve its robustness. As I intend to submit a PR on this in the near future I can also include code changes that will prevent negative flow through an emitter if the community agrees that this is warranted.
Thank you @LRossman. The submitted example was simplified so as to see right away the problem with negative emitter flows. Originally the nodes with emitter have also demands on them but since Epanet GUI's actual demand only has the combined water demand, instead of actual node demand and emitter flow, I removed the base demand so that actual demands were only by emitters. I first noticed that actual demands were reduced when the node pressure was negative. Node 3 should not have a demand below 100, but for all the times it has negative pressures, actual demand were all reduced to below 100 because of the negative emitter flows.
I would be nice if the actual demand in the report can be also be separated into the actual demands and emitter flows.
PR #706 has been submitted that adds a new global hydraulic option, EN_EMITBACKFLOW, that allows back flow (negative flow) through emitters if equal to 1 (the default) and prevents back flow if equal to 0. The attached file, based on @allenmlowe 's example, provides a test of this feature. EmitterTest.inp.txt
With back flow allowed, the flow through the emitter at node W-1 is:
while with back flow not allowed we get:
