OpenWaterAnalytics
Fix pressure breaking valve: valve will generate head instead losing, when the flow is negative
Currently, negative flow through a pressure breaking valve will cause the valve to generate head instead of losing it. It is much more sensible for the PBV to always cause head losses, regardless of the flow direction through it. This way the PBVs can be safely added into the network, even when the flow directions are not known beforehand.
I agree that the proposed change makes logical sense, but there are two mitigating factors that need to be considered:
- it will break backward compatibility
- it will break the answer to the How do I size a pump to meet a specific head? FAQ in the EPANET Users manual.
Looking at the bigger picture, one can question why a Pressure Breaker Valve is even included in the program. As far as I know there is no commercial version of a valve that provides a specific pressure drop across itself (someone please correct me if I'm wrong). Even if there were, what practical purpose would such a valve have (i.e., what good is specifying a pressure drop independent of knowing what the actual pressure level is). The term "pressure breaker valve" usually refers to a pressure vacuum breaker valve which is something totally different (it's a check valve that closes when the line pressure drops below atmospheric pressure to avoid a possible backflow condition).
For these reasons I would have to vote against implementing this change (but I'm willing to be convinced otherwise).
I must say I have never used a PBV.
@makusuko, can you elaborate on the use case?
Thank you for the start of discussion.
Yes, I am aware of the constant head pumping use-case for the current implementation, although I would rather implement that kind of support for flow, pressure and head controlled pumps "properly", e.g. using the pump battery component described in https://www.sciencedirect.com/science/article/pii/S1877705815025977 instead (as we have done in Fluidit's version of EPANET).
The question of backward compatibility, of course, is already a harder one to be answered. In my opinion breaking backwards compatibility is fine when rarely done in new (major) version upgrades and it is properly documented in the release notes. Especially so when the breaks occur due to fixing bad or unexpected behavior or the fixes don't affect typical use cases.
Here I would argue, that because a physical valve can never add head to the system, it is very dangerous to have this kinds of corner cases in the simulator either, as the engineers expect the model to replicate physical behavior of the system. Rather than leaving a feature like this to linger, a new component for solving the original problem would be better option. This might warrant for breaking the few cases, where people rely on this behavior.
But this, as said, is only an opinion regarding a wider and complex issue, and I am sure there can plenty of valid counter arguments.
Regarding the uses for pressure breaking valves (i.e. controllable fixed pressure loss): they (as physical devices) are very widely used in district heating networks and that's where I mostly encounter them. In the DH world they control not the pressure per se, but instead the pressure difference between the supply and return pipes. Even more often, they systems pair pressure breaking valve with a constant generated head (VSD controlled) pump and the setting is kept the same for both, i.e. the supply pump generates some amount of head and the valve in the return pipe causes the same amount of pressure losses - this way the control is symmetric in terms of the pressure changes in supply and return networks..
I also use PBVs regularly to model (and control) the losses in water treatment processes and to model ground water level changes due to water extraction, and I have seen them being in use in couple of East European WDN models too. Often the need for the component is mostly modeling-practical, but in many cases the real world use case also involves controlling the pressure drop rather than the inlet or outlet pressure. Basically, from control system (model) point of view, it is often nicer to control the pressure drop.
When it comes to the numerical stability of the simulations, pressure breaking valves and constant generated head pumping are much more stable and converge faster, compared to FCV, PRV or PSV style control or pumping, but of course the cases where this can be effectively utilized, can be rare-ish.
@makusuko thanks for providing a use case for the PBV. However it appears that the fix you provided doesn't work when there is not enough head available to achieve the required PBV head loss setting in the positive flow direction. I ran your commit against the attached NET1-PBV.inp file (the same file that caused it to fail the regression tests) and the iterations never converged. Restricting a PBV to not generate head appears to be a challenge, and might require implementing status checks like we do for PRVs/PSVs. NET1-PBV.inp.txt
given the amount of deliberation on this PR, i suggest that we move discussion to an Issue thread to talk about use cases and implementation prior to reviewing code.
Any objections to closing this?
I agree that this issue (PBV generating head) should be moved to an issue thread since it is a real problem and a robust solution for it has still not been found.