Downstream Trace Crossing into Another Subnetwork and Failing with ERROR 001890

[JohnGoat]

Hello,

I am working within the same Tier where two different Subnetwork Controllers generate two different SubnetLines:

1724 → Yellow SubnetLine

1734 → Blue SubnetLine

Both subnetworks exist in the same tier but are created from different subnetwork controllers. For clarity, I will refer to them as Yellow (1724) and Blue (1734).

Scenario

I place a starting flag on a feature.

I run a Downstream Trace.

My intention is for the trace to stop at devices where:

OS (Operational Status) = Open
(Configured as an Attribute Filter Barrier)

Additionally:

NS (Normal Status) is used as a Tier Condition Barrier.

Observed Behavior

The trace starts within the Blue subnetwork (1734).

It then transitions into the Yellow subnetwork (1724).

If there is a device ahead with OS = Open, the trace correctly stops at that device.The tracing changes from the blue line to the yellow line, and the tracing process stops at OS=Open.

However, if there is no device with OS = Open ahead and the trace encounters the Yellow Subnetwork Controller, the trace fails with:

ERROR 001890: Invalid subnetwork connectivity, multiple subnetwork controllers with different subnetwork names found.

 

Expected Behavior

Even if no OS = Open device exists ahead, I expect the trace to stop when it reaches a Subnetwork Controller belonging to a different subnetwork.

I also tried adding a Filter Barrier:

Is Subnetwork Controller = True

However, the trace still returns the same error instead of stopping at the controller.

Question

Why does the trace continue into another subnetwork within the same tier instead of stopping?

Why does adding Is Subnetwork Controller = True as a filter barrier not prevent the ERROR 001890?

Is this behavior by design when tracing across multiple subnetworks within the same tier?

What is the recommended configuration to ensure a downstream trace:

Stops at OS = Open devices, and

Stops when encountering a different subnetwork controller,
without generating ERROR 001890?

Any clarification on correct trace configuration in this type of multi-controller tier setup would be greatly appreciated.

Thank you.

[MikeMillerGIS]

Is the device between the blue and yellow a subnetwork controller?  Can you verify the blue line is connected to a different controller than the yellow line?

[JohnGoat]

The device located between the Yellow and Blue lines is not a Subnetwork Controller. This device is positioned at the boundary between the two subnetworks.The Blue and Yellow lines are connected to different Subnetwork Controllers. Their names are labeled on the map:

1734 represents the Subnetwork Controller name for one subnetwork.

1724 represents the Subnetwork Controller name for the other subnetwork.

So although the subnetworks are adjacent at that device, they are fed by separate Subnetwork Controllers.

@MikeMillerGIS 

[MikeMillerGIS]

Then you need to define a condition barrier that separates those two subnetworks at that device.  You need a condition barrier for both NS is open or OS is open. 

[JohnGoat]

If I define an Open condition barrier for both NS and OS, the trace correctly stops at that device.

However, my intention is different. I want the downstream trace to continue past that device and proceed all the way to the Yellow subnetwork’s Subnetwork Controller.  

 The label is probably unreadable.

[MikeMillerGIS]

You will need to open another device to isolate the yellow subnetwork from that section then.  In the current state, the network sees two subnetworks on that line.  Meaning it is energized from both directions.  

[JohnGoat]

Yes, the device is energized from both directions, and with the current configuration I am able to continue the trace from the Blue line into the Yellow line.

The issue occurs only when there is no device on the Yellow line with OS = Open ahead.

In that case, the downstream trace continues all the way to the Yellow subnetwork’s Subnetwork Controller, and at that point the trace fails with the error. 

[MikeMillerGIS]

The only other way is added a directional device so the blue controller cannot trace to the yellow controller. Something like a network protector right after the yellow controller.

[RobertKrisher]

This is working as designed. If you cannot have two subnetworks with different names connected to each other. If in the field this area is always fed by the two sources, then they should have the same subnetwork name. If they are only fed by one or the other, then model the device as open to separate the networks. Trying to artificially separate the networks with a closed device won't really work, as you'll see below.

A feature is only a subnetwork controller if it belongs to an asset type that has all the correct configuration (subnetwork category, directional terminal config, associated with a subnetwork definition in the controller role) AND you have used the modify subnetwork controller tool to enable it as a subnetwork controller. If you want that trace to stop at the "possible controller" when it's CLOSED and NOT a subnetwork controller you could add a condition barrier to stop at features that have the Subnetwork Controller network category (which may have unintended consequences) or you could use a network category specific to this situation.

The problem with doing that is that if this 'possible controller' will ALWAYS stop tracing, regardless of state or configuration. Which means that if you ever wanted to feed the area from the yellow source instead of the blue source you'd need to remove the device.

[RobertKrisher]

This is a known limitation of the way that subnetworks are modeled. To work around the issue you can model an open point (or other barrier) to separate the two subnetworks, which you have already discovered. Please log an issue and get yourself associated with BUG-000173401.