Break-pressure tanks in EPANET

[Maxim F.]

Hi group,

This question would be targeted specifically to people who have
experience in designing gravity-flow water distribution systems.

Break-pressure tanks (BPTs) are generally an important component of
the network. They enable you to control the head and pressure in your
system when you have high elevation differences while going down the
pipeline. In your experience, how should one proceed to include those
components in an Epanet model ?

Conceptually speaking, a break-pressure tank bring down the pressure
to 0 m (relative to the atmosphere) at a specific point in the
network. After some online research and my own experiments, here are
my findings.

On other discussion boards, people suggested using reservoirs as a
BPTs. However, I noticed that this often results in messed up flows
within the system, because sometimes the reservoir will take in water,
and sometimes multiple reservoirs interconnected create very weird
flows when interacting together (i.e a reservoir will supply 10 LPS to
another one when the total flow in the network is around 1 LPS). This
problem could be avoided with flow-control valves (FCV) to control
upstream and downstream of each reservoir, but you end up with a
rather complex system if there are many BPTs.

Another suggestion I saw is to model the upstream and downstream of
each reservoir as a different network. I haven't had much success with
this option yet, and you have to be very careful about the demand
(either positive or negative) you enter at nodes that are supposed to
mark the end of "sub-networks".

The last option I saw is to insert a pressure reducing valves (PRV)
just upstream of the node where a BPT would be located. You set this
PRV to a 0m head, which should have the same effect as a break-
pressure tank would have. This is rather simple to add to the model
and I have had interesting results so far with this option.

Is there anyone who faced a similar situation ? How did you model such
components, and how did it compare to what you saw on the field later
on ?

Thanks a lot,

Maxim

PS. How can we insert files or images to our posts in this group ? I
see no such option.

[Lucas Vasconcelos]

Hello Maxim,

The best approach I found so far is actually quite similar to yours, I just use a pressure sustaining valve to keep the pressure in the upstream node in a minimum value. This way the program limits the flow to assure this pressure.

The "most correct" solution would be actually modelling the tank, but the software can't handle these tanks well. This is what I think it happens:

In epanet's model, tanks must have an minimum and a maximum level. Below minimum level, there is no outflow. Between them, there is inflow and outflow, and when the maximum level is reached, there is no more inflow. 

Besides that, the software is quite smart. It makes the calculations in entire timesteps. If it notices that within the last timestep a "rule" was broken (for instance, a tank below minimum flow had outflow, an tank had inflow after reaching the maximum level, other internal rule or even an user's control rule), it recalculates a new timestep and remakes the calculations to apply the broken rule.

A pressure breaking tank, though, has almost no volume between the minimum and the maximum levels. They're the same. This situation forces the program to impose a lots of new timesteps.

Add to that the (common) possibility that the pressure breaking tank (I'll just write PBT from now and on) is connected to an actual tank downstream. The PBT will have lots of available head to provide flow to the tank, thus causing a very high flow.

So what you have is "tank is opened, flow = (absurd value). Within the time step tank closes. Recalculate. After closing, tank fills quickly. Recalculate. Tank is opened...". You're likely to get an system unstable warning. When you use a flow control valve to impose a maximum flow, you somehow avoid the absurdly fast reaching of maximum and minimum levels, but depending on the situation you might still have the problem.

In a number of situations I've just set the attempts to a higher number (default is 40, I've gone as far as 100.000) without correcting the system unstable error.

The pressure sustaining valves mechanism seems to be different, I'm not sure which is, but it works nicely and running times are quite reasonable.