Pressure Tier Troubleshooting Tips for Connected Pipes

[PeterKing]

Hello,

I am attempting to update our final pressure zone and are receiving errors that multiple subnetwork controllers are present. When performing a subnetwork trace, we receive the "Invalid subnetwork connectivity, multiple subnetwork controllers with different subnetwork names found" error.

I have updated all subnetwork controllers based on engineering drawings and worked with our utility to ensure that terminals are properly configured. We have also begun on lower pressure tiers and worked from the periphery of the service territory to the inside. 

The connected trace selects all mains even when the filter barrier is set to subnetwork controllers

What is the best way to troubleshoot connectivity to determine the subnetwork controllers that are connected to the starting point/pipes in the final pressure zone?

Any guidance is appreciated.

Thanks!

[ErikRose · Accepted solution]

Place trace points in two subnetworks that should not be connected, then run a shortest path trace.  This should determine how and where your subnetworks are inadvertently connected.

[gis_KIWI4]

@PeterKing - Taking a guess here without have a look at the data but can you double check the subnetwork definition for that tier and ensure there is barrier condition (open valve or something) for the trace to stop. 

At face value the error is because there are 2 separate subnetworks that are merging into one another. The system expects an isolating feature where two subnetworks meet. For example two separate subnetworks xyz and YYY are merging without an isolation device separating them.

Some of the common failures in this situation are when both lines are connected to the same terminal of the isolating device.

Another cause is when two subnetwork controllers feeding the subnetwork have different subnetwork names. For example below is subnetwork that is fed by 2 controllers A and B but if they are setup with different subnetwork names then that will lead to an error. 

As for fault finding, after you update the subnetwork and it fails it should create a subnetwork error around all the subnetwork controller that are contributing to the issue. This might help you isolate the problematic ones.  

EDIT - Also the test for doing a connected trace with just subnetwork controllers as filter barrier will most likely result in selection of the entire network because the connected trace will "pass through" open/isolating devices. From the screenshot yours looks like a meshed network so it is expected that the trace will find a way to all the features.

If you want to use connected trace + barrier features then use more than just the subnetwork controller condition. Maybe add open devices, lifecycle status etc. 

[RobertKrisher]

The shortest path trace is the way to go. But it has two limitations, similar to the connected trace, because it doesn't rely on subnetworks:

• You need to manually add all your condition barriers to prevent them from passing through closed valves
• These traces will ignore the directionality of terminals (without a subnetwork controller to define sources/sinks, there is no upstream/downstream)

You can find an example of this in the Perform quality assurance on subnetworks tutorial on the Learn site.