Subnetwork pressure zone trace (water)

[GavinMcGhie]

Hi all- I've set up our UN, cleared all the errors, and started playing with subnetworks. Thinking I'd start simple with a high level pressure zone, with one pump station feeding it and one pressure reducing valve ending it. I made the Pumpstation the controller and ran the pressure zone trace. Unexpectedly, the trace ran right through the regulator valve and selected 2 full pressure zones. Oddly the trace did stop at the check valves. I confirmed that both valves and connected pipes have the correct terminal settings. It's also possible that the trace went both directions from the pump station, but this seems less likely. Anyway, I would expect a preconfigured pressure trace to stop at a PR valve? Or do I need to make that a controller for the lower system before setting the upper system? Also, I can't find any info on why a check valve stops this trace and a PR does not? Am I missing something?

Thanks, Gavin

[RobertKrisher · Accepted solution]

@GavinMcGhie A picture, or two, is worth a thousand words in this kind of situation, but I'll do my best to extrapolate your words into a mind-network 😁 We have an entire playlist of content devoted to understanding how to use the water utility network, for these kind of issues I'd recommend you either read the Water Quality Assurance article or read/do the Perform quality assurance on subnetwork tutorial (which covers several scenarios similar to this on a water dataset)

The subnetwork trace will stop when it encounters either another subnetwork controller, a condition barrier, or a device whose terminals it cannot traverse. I'll break down your situation into two parts, sorry for the verbose responses.

1. Pressure Reducing Valve

The reason why your trace didn't stop at the pressure reducing valve for the lower system is because you haven't set up as a subnetwork controller yet. This is why we recommend you start with the lower systems (they also tend to be smaller). Pressure reducing valves are also devices that have a directional terminal configuration. Because you said the PRV was for a lower system, it sounds like your terminals are assigned correctly (water is flowing from the higher-pressure/upstream subnetwork to the lower-pressure/downstream subnetwork).

1. Terminals

The reason why the trace stopped at the check valves is because check valves have a directional terminal configuration, and your trace encountered the check valve on the edge connected to the downstream. Water is a source-based network which means that pressure is only allowed to move from the upstream terminal to the downstream terminal.

If you think the trace should have continued, then you will need to 'flip' the terminals by connecting that stopped in your trace to connect to the downstream terminal and the line on the other side to connect to the upstream terminal.

There are examples of this exact scenario in both the articles and tutorial I referenced above. You and your engineers know which edge is supposed to be the upstream edge/downstream edge, and once you know you'll need to let the utility network know so it can trace appropriately.

[GavinMcGhie]

Hi Robert- Thanks for the feedback, and agreed that if I were working from lower to upper systems, this might not have come up since I would have set that PR as a controller before getting to the upper system. However, in our system, the high systems tend to be the smaller and easier systems to work with, so i started there. It sounds like the Pressure Reducing Valve needs to be set as a controller for the lower network in order for it to stop the trace on the higher zone? I have already reviewed both of those links thanks.

This seems wrong to me for a pressure zone trace? In what case would a PZ trace NOT stop at a PR valve (from either subnet), when in fact the whole point of that valve is to change the pressure? I see that in other trace types this might not be the case, but for a PZ trace, a PR valve seems to be an obvious asset to stop at (and what we have used with the GN for decades).

I'm guessing that the reason the PZ trace stops at the check valves and not the PR is related to flow since both are directional? As I think you indicated, flow for a check valve moves toward this upper subnet, while flow for an RG moves out of the subnet. That said, I can make it work, but it sure seems like a limitation to the PZ trace process. If the PR was honored, all I'd need to do is set the controller(s), run the trace, and be able to tell immediately if a PR valve was missing or configured wrong for that subnet. I guess I don't understand the "why" of it since it seems like a limitation. Anyway, thanks again for the feedback!

cheers, Gavin

[RobertKrisher]

Gavin,

  By default, the subnetwork trace is configured to stop at the boundaries of your configured subnetworks, in this case, pressure zones. Once you've configured all your subnetworks, everything will work correctly.

If you wanted to have the trace stop at the pressure reducing valve, even though it wasn't configured to be a subnetwork controller, you could always just add a condition barrier to your trace to stop at pressure reducing valves. This would cause the trace to stop, even if the pressure reducing valve wasn't configured to be a subnetwork controller. I have seen customer datasets that contain pressure zones that don't stop at pressure reducing valves, but they're pretty rate (only a handful of such situations for several hundred pressure zones).

[GavinMcGhie]

Thanks again Robert

The only case I could think of for not automatically stopping a PZ trace at a PR valve would be when a utility has pressure zones that span across PR valves. This seems illogical, but I'm sure it happens. I guess I was just arguing logically for the PR valves to automaticaly work as a barrier since this is what I had expected, but I do now understand what is required to make it work within the current constraints and have successfully delineated the test pressure zone with this new info!

Thanks, Gavin