Hierarchical Water Subnetwork

[AmberY]

Hi, 

We were in the midst of building subnetwork and understand that "Hierarchical networks only allow features to belong to more than one subnetwork as long as those networks belong to different tiers".

But during the process of building subnetwork, it turns out that the asset of water line is belong to more than one subnetwork. Is this a glitch or if there is something we didnt aware of? 

Run subnetwork tracing of this system subnetwork A, B, C, D respectively all return the same coverage area. 

Appreciate all the thoughts. Thanks so much!

[RobertKrisher]

There are a few edge cases to this rule. Firstly, a feature can belong to many subnetworks without an error if the feature acts as a barrier between multiple subnetworks. Think of a closed valve between two pressure zones.

Another less common situation is when a feature is in an area fed by two different subnetworks, but the subnetwork controllers themselves aren't connected. This can happen if you have something like a pressure zone that is fed by different water systems, but the valves in the area prevent water from one system from entering the other system.

From the screenshot it looks like you are not using one of the utility network foundations, so it's for me to speculate what could be going on in your situation since I don't know how your data is configured.

[AmberY]

Hello @RobertKrisher ,

The Water System Tier is configured with these parameters.

And we have only build system subnetwork for now and have little clue on why the subnetwork behave these way. As in some region, the subnetwork is overlapping but in other region, the subnetwork hit error 29 for overlapping. 

First case seem not applicable to our case as i can see that the water line and other non-barrier feature are belong to 5 system subnetwork even it is not a barrier. For case two, I am not sure how to verify if this is the case, appreciate if you could share some thoughts on this. For context, we only performed "Assign Terminal Connections" for terminal devices and directly build the subnetwork due to certain reason.

Thanks so much!

[RobertKrisher]

@AmberY it appears you have the second issue, can you draw a high-level diagram of what your system subnetwork controllers/subnetwork look like? It is very unusual for a feature to belong to two water systems, let alone 5 systems. My gut feeling is that this is all actually a single system, but seeing how you're representing your different supplies/sources (wells, treatment plants, interconnects, etc) will help me understand.

The reason why sometimes you get an inconsistent subnetwork name (the fact that you call it an error 29 warms my heart) is because the two controllers are connected. I discuss several examples of this in the water subnetwork quality assurance article. You can find the path by using the shortest path trace.

In instances where the subnetwork controllers are separate by devices with directional terminal configuration, like in the screenshot above, you will end up with a line with multiple systems. I discuss an example of this in the cross-fed section of the subnetwork quality assurance tutorial.

[AmberY]

Hello @RobertKrisher ,

This is the tier where we’ve configured the subnetwork controller. Appreciate if you could have a look and share any insights or idea you might have? 

Thanks,

PY

[RobertKrisher]

Ok, looking at the diagram above a feature in the right-most DMA would have:

System: 1

Pressure: 3 

DMA: 4

In order for the subnetwork names to be concatenated you would need something like the following:

If there was only a single backflow preventer (or pump or some other directional device), then you would get an inconsistent subnetwork name because one of the system subnetwork controllers would be able to be connected to the other controller, and they have different names.