Substation Tracing

[KokilaM]

Hi Team,

I'm currently setting up the trace configuration inside an electric substation as follows:

• Up to the Step-Down Transformer → Transmission Tier subnetwork
• Step-Down Transformer to Circuit Breaker → Distribution Tier Subnetwork A
• From the Circuit Breaker onward → Distribution Tier Subnetwork B

After configuring the subnetwork controllers, I ran Update Subnetwork. My expectation was that Subnetwork A would trace only up to the Circuit Breaker. However, it is tracing past the circuit breaker instead of stopping there.

I've also confirmed that the controllers I defined are all set for the Distribution Tier only.

Could you help me understand why the trace isn't terminating at the circuit breaker as expected?

@RobertKrisher @MikeMillerGIS 

Thanks

[MikeMillerGIS]

What settings did you us in the Trace?  Did you set a target tier?  

[KokilaM]

I ran a subnetwork Trace

[gis_KIWI4]

@KokilaM - we got past this by setting a traversibility filter in the subnetwork definition to stop at a subnetwork controller. 

[KokilaM]

Can you please help me with this ?

[gis_KIWI4]

@KokilaM - so what's happening here is that Distribution Tier Subnetwork A and Subnetwork B have the same "valid" objects. So subnetwork A continues and overlap subnetwork B.

Subnetwork A needs to stop at the point where Subnetwork B begins i.e the feeder circuit breaker.
To do that, add another condition in the subnetwork definition. 

ISSUBNETWORKCONTROLLER  = YES

After that the SUBNETWORK A should stop at the Circuit breaker which is subnetwork controller of SUBNETWORK B

[RobertKrisher]

@gis_KIWI4  That shouldn't be necessary unless the lines in the substation are connected to the same terminal as the lines outside the substation. This is something that can accidentally happen depending on how the lines connected to the breaker are modeled and how the rules are configured.

When a subnetwork trace attempts to traverse a terminal associated with a subnetwork controller it will automatically stop, even if there isn't a condition barrier defined telling it to do so. In the case of a partitioned, source-based domain like electric this can have several outcomes:

If the connection is from a different line to the terminal of the controller, and the controllers have the same subnetwork name, then the system treats this as another controller for the subnetwork for the purposes of calculating flow direction.

If the connection is from a different line to the terminal of the controller, and the controllers are associated with different subnetworks, it will be an inconsistent subnetwork error. There is a similar error if the controller belongs to a different tier.

If the connection is from a different terminal on the device and its crossing the internal edge (i.e. terminal path) of the device, then the subnetwork trace will stop and no error will be returned. Even if the other controller has a different subnetwork name or belongs to a different tier.

By setting up a condition barrier to stop at a device that is a subnetwork controller, you are forcing the trace to stop as soon as it encounters a device that is a subnetwork controller, even if the trace doesn't traverse to a terminal associated with a subnetwork.

[RobertKrisher]

If you look at the sample electric utility network foundation for north station unit 1 and RMT003 you'll see how its configured. As long as both the power transformer and circuit breaker are configured as subnetwork controllers AND the lines associated with each subnetwork controller are connected to the correct terminal it should work correctly.

Can you post a screenshot of what is selected when you trace subnetwork b (circuit breaker) and subnetwork a (the station)? I want to see that before I make any predictions about what is going on.