Electric Radial Partitioned Tier Source– Why Are Loops Not Flagged as Errors?

[JohnGoat]

Hello,

I have a question regarding loop behavior in a Utility Network configured with the following setup:

Tier type: Partitioned

Subnetwork controller type: Source

Tier topology type: Radial

In my scenario:

A subnetwork controller (Source) feeds an overhead line.

The line branches into two paths (a fork).

Further downstream, those two paths reconnect and form a closed loop.

There are no switches, protective devices, or normally open points between the branch and the reconnection.

Running Update Subnetwork does not return any errors.

The subnetwork remains valid and does not stay dirty.

Electrical engineering perspective, this creates a cycle within what is intended to be a radial feeder.

My understanding from the documentation is that:

Loops are expected in mesh networks.

In radial networks, loops typically indicate an error condition.
However, the system does not appear to enforce this automatically.

So my questions are:

Is loop detection in a radial tier expected to be handled manually using a Loop trace?

Is this behavior by design? What configuration can I use to return a short circuit error?

If strict radial enforcement is required, what is the recommended best practice?

Thank you in advance.

[RobertKrisher · Accepted solution]

The key phrase in your write-up is that loops are typically errors. Because an error in our system has no exception, if you configure your tier to now allow loops that means that you can never have even a single segment of line that has indeterminate flow. We have discussed implementing something like this, but almost every customer dataset has a few areas that are intentionally looped, so if we added a means to enforce this, we would also need to add a means to create exceptions.

Most customers just add running a loops trace to their QaQc process, which is what you indicated above. Our standard model even has a field you can use to track whether features are intentionally indeterminate (IsValidLoop). If you wanted to do strict enforcement of this, you could add a step to your QaQc process that would run a loops trace on the subnetwork before running update subnetwork (and after validating topology) that would prevent you from updating the subnetwork if any looped features were discovered. Just make sure to build in a way to allow for exceptions.

You may be tempted to use the allow indeterminate flow option available when running an upstream,  downstream, or upstream trace, but this option only has the trace stop at indeterminate flow it does not return an error.

[JohnGoat]

First of all, thank yo @RobertKrisher 

While reviewing the data schema, I noticed that the IsValidLoop field is defined. However, it does not appear to be a system-maintained

From an operational perspective, it would be quite useful if this field were automatically populated for features that are part of a loop during the Update Subnetwork process.

Instead of identifying looped regions through a trace operation each time, the system could consistently maintain and populate this field as part of the subnetwork update workflow.

This would provide significant advantages operationally, since looped areas could be directly queried, symbolized, and validated without the need to execute a separate trace process.

I believe having this information persistently stored at the database level would improve usability and data management efficiency.

[Jens_Dalsgaard]

What is a loop?

Allow me to describe a scenario not uncommon in an underground (cabled) network.

1. As consumption increases in a given area, rather than removing an existing cable to add a new cable with a larger nominal current you might leave the existing cable and add a new, parallel cable with same electric properties (cheaper). This way the DSO doubles the amount that can supplied.
   Yet, such parallel cables would technically form a loop.
   
   
2. On higher voltage it is not uncommon to use individual cables per phase rather than one cable holding all three phases. And you would want to document each of these three cables (each with appropriate phasing applied). 
   Again, unless you take into consideration the phasing in the comprehension of a loop, such three cables would make up a loop.
   
   
3. Finally, in part of the grid operated as meshed entire parts of the grid would become a myriad of loops.

Hence, we need to allow looping in the grid. 

That said, I recognize loops often being caused by data quality issues, so perhaps a way to look for a useful solution would be to somehow flag certain loops as valid. Yet, how should we do this? I wouldn't want to update hundreds of features participating in a loop and there is no overarching loop-instance that we could flag as valid. Hmmm?

[gis_KIWI4]

I agree with @Jens_Dalsgaard - We have a couple of instances where we have done the same thing and we treat these "loops" as normal. So yes, looping needs to be allowed. 

@JohnGoat - we haven't found a way apart from what @RobertKrisher suggested, implementing loop traces in your QA/QC process. 

A possible enhancement request could be a flag on the Subnetwork - "Loops allowed" (Similar to the Set Subnetwork Definition option of allowing Disjoint Subnetworks; this would be set a set at a Subnetwork Controller level) 
So if you have a pure radial network without any instances of parallel cables, etc you set that flag to False. 
During validation, it sees a loop and marks it dirty. 

But I am not convinced if it truly solves the problem but rather creates more gotchas. 

You could also implement post update overnight verification process.
1) Maintain a list of subnetworks with "valid loops" 
2)Batch Trace your network to find loops within all the subnetworks.
3)Compare against the maintained list. 
4) Report Outliers.