Trace - Barriers are not honored by the Trace Tool

[gis_KIWI4]

Hi Team, 

Wondering if anyone has faced this before.
We have a Utility network service running but the trace does not seem to be honoring the barrier conditions. 

The use case is simple I want the trace to stop in 2 scenarios - Switch Status = Open OR Feature is an End-Point feature. Let's ignore the End Point for now and look at the Open Switch. 

 

This is what my Trace parameters look like  - 

(I have also tried changing "Open" to 1, as that's the number in the domain but no luck) 

Result  - 

I would have expected it to stop at the switch.
Anything I might be missing here? 

Thanks in advance 🙂 

PS - I ran into this issue when creating subnetworks. Because subnetworks don't stop at these features, subnetworks with different subnetwork names overlap and the system doesn't like it. Updating the subnetwork definition with these conditions did not work so I using the Trace tool to troubleshoot. 

[MikeMillerGIS]

Those switches where not selected in your trace results.  My guess is they are not connected to the network.  Can you run a find connected trace and see if they are returned?  If they are not, check the line to ensure there is a vertex at that switch location and that vertex is at the same XYZ as the switch.

[gis_KIWI4]

Hi @MikeMillerGIS - 

The switches are being selected in the trace, which is a problem.
I also tried running the connected trace and still the same result. 

Result - 

Expected Result - 

[RobertKrisher]

@gis_KIWI4  Check to see if the two lines are connected to the same terminal, the condition barrier will only apply if the connectivity passes through the device.

[MikeMillerGIS]

Also, can you just select that line with the open switch.  Is that all one big line?

[gis_KIWI4]

@RobertKrisher - I hadn't made any terminal assignments assuming that it will still work as a barrier when the trace works its way though the devices. 

I have tried to assign terminals - I can only assign the lines to Terminal 1 (Terminal two is greyed out). 
When I connect both the lines to Terminal 1 and run the trace, it fails to stop at the device. 

Can you confirm the following. 

One line should connect to "Terminal 1" of the switch and the other to "Terminal 2" and that would mean it's passing through the switch?  

[gis_KIWI4]

Just reporting back - Terminal 2 was greyed out because it never made it into the JE Rules. Will get that sorted. 
Assigning the lines to different terminals worked like a charm.

So am I right in saying that if a device has terminals then they need to be properly assigned before using that feature as a barrier.

[RobertKrisher · Accepted solution]

@gis_KIWI4 yep, that's the problem. A device with terminals will only act as a barrier for connectivity between the terminals, but if everything is connected to the same terminal the device can't act as a barrier because the connectivity is considered to not pass through the device.

The fact that you encountered this likely means that you either created your own model from scratch or altered one of the existing models and only added rules for one terminal of the device. Normally if you were to have a line that could connect to either terminal and you forgot to specify which one, you would get an ambiguous connectivity error that would force you to connect the lines to each terminal on the switch.

[gis_KIWI4]

Yup, we have created our own model from scratch and in the process of migrating our GN to UN.
Thanks again for all your help @RobertKrisher , @MikeMillerGIS  and @JoaquinMadrid1 

[JoaquinMadrid1]

@gis_KIWI4 Glad you got it resolved... it can be tricky, particularly because connecting both lines to the same terminal does not create any dirty area.

By the way, you may want to evaluate the advantages and disadvantages of configuring Terminals in a case-by-case scenario. Then, you may decide that for some Asset Types they are necessary while not needed for others. 

At SSP we have made such evaluation and tweaked the Electric Foundation resulting in a model where Terminals are only assigned when absolutely necessary to support OOTB Network Management functionality, particularly Phase Propagation. In this way, it is possible to implement a Geo-Coincident Bank/Units UN in which only Subnetwork Controllers, Service Transformers, Capacitor and Phase Tappers/Splitters are configured with Terminals.

Furthermore, with the appropriate set of Junction-Edge Connectivity Rules when snapping these points to lines you do not even need to worry about adjusting the line's FROMDEVICETERMINAL and TODEVICETERMINAL. For example, if you only have rules between the Hi Side of the Transformer and Primaries and the Lo Side to Secondaries then, when snapping a Transformer between two Primary Lines where some secondaries also converge the rules ensure that the Transformer is connected to the Primaries via the Hi and to the Secondaries via the Low.

Deeper in the example, consider now that this was a single phase Transformer, say B-phase, snapped between to segments of 3-phase Primary where also 5 Secondary service lines spread out to their Service Locations. If you set the phase of the Transformer to B, then Propagation will bring ABC from the upstream Primary to this point, continue pushing ABC to the downstream Primary and allowing the transformer to "tap" the B-phase and pass it down to the Secondaries.

(NOTE: In our evaluation we confirmed that equipment such as fuses, switches, reclosers, sectionalizers, Service Points, Distributed Generation, etc... can be modeled without terminals and still support OOTB UN functionality, such as Operability-by-Phase, while simplifying the editor experience.)

I hope this is helpful.