nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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!

Find more posts tagged with

Accepted answers

ErikRose

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.

All comments

ErikRose

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.

PeterKing

Thanks to all for your responses! The tracing guidance was helpful but I wanted let the group know that the cause and fix were much simpler than running traces.

I discovered that a transmission main had connectivity to a distribution main via errant taps which caused the error between the two pressure tier zones.

Thanks again all!

RobertKrisher

@PeterKing It breaks my heart to see that someone went through all the trouble to do the hop over the transmission main, only to have a fitting created to connect them. But then again, it may just be payback for not having done the hop on the third line (which somehow was spared from getting a tap).

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.