Subnetworks vs. Digitized Direction

[NathanHeickLACSD]

I'm trying to apply the concepts of subnetworks and tiers to our sewer system.  It appears that subnetworks were designed for systems where the resource flows out of a source or into a sink.  It looks like the subnetwork controller determines the flow direction in the subnetwork.  A subnetwork in a sewer system would be analogous to a tributary area.

However, our system has manholes where flow bifurcates into multiple paths.  Instead of paths always consolidating, sometimes they split.  A point can drain to multiple sinks.  This would lead to multiple subnetwork controllers.  Can a node or edge in the UN participate in multiple subnetworks?  The option of using digitized direction like we did in the geometric network may be required for us.

Next, are subnetworks and tracing by digitized direction mutually exclusive?  If both are possible, would the subnetworks be defined using digitized direction in your subnetwork definitions?

Finally, are subnetworks and tiers required at all?  I can see why they would be necessary if you have no other way to define flow direction.  If you do use digitized direction, can you just never setup tiers and subnetworks?  I notice they don't exist when you build a UN from scratch.  What functionality do they enable?

[gis_KIWI4]

@NathanHeickLACSD - Tracing using digitized direction was developed you don't need the functionality of subnetwork controllers. You can do "upstream" and "downstream" without subnetwork controllers and subnetworks. And because there are no subnetworks - The options for "Domain", "Tiers" etc are not relevant. 

The solution that uses digitized tracing sits somewhere between - No Traceability and UN with subnetwork controllers. Think of is a simplistic version of tracing where you help the trace by guiding it with attributes. 

The subnetwork controller and subnetwork are pretty powerful in industries like ours where open or closing a switch can drastically change the flow of electricity. If we didn't use subnetwork controllers then we would have to manually set the flow direction attribute on each of the affected line segment. 

https://www.esri.com/arcgis-blog/products/utility-network/water/utility-network-digitized-direction

Regarding the first part of the question (coming from someone who hasn't had too much experience working in that industry) - I believe that sewer networks are modeled Hierarchical as opposed to Partitioned. 
If you want an edge participating in multiple subnetworks then Hierarchical is the way to go. 

Hope that helps 🙂 

[RobertKrisher]

When you do an upstream or downstream trace, you must either choose to use a domain/tier or you must choose digitized direction. You can run a digitized direction trace in an area of the network that has subnetwork controllers, but the trace will ignore the controllers to determine flow.

A section of your network can belong to multiple subnetworks (within the same tier), as long as the controllers themselves can't connect to each other. In your example, if that manhole normally bifurcates flows, even when it is not under significant flow, then the area upstream of a manhole that bifurcates flow would belong to multiple tributaries and therefore multiple subnetworks.

If the bifurcation only occurs when there is enough flow in the system, then the area upstream would only belong to a single subnetwork since under normal conditions water cannot flow to the second tributary.

[NathanHeickLACSD]

Thanks @gis_KIWI4 and @RobertKrisher.  My follow up questions are:

1.  Can subnetworks be defined using digitized direction?
2.  What won't work if you do not set up tiers and subnetworks and use digitized direction only?  Is it just the subnetwork trace?  Is it also the isolation trace?  Is there any other functionality in the UN that depends on it?

[RobertKrisher]

1 - No

2 - You won't be able to run subnetwork, subnetwork controller, and isolation tracing. You will only be able to run upstream/downstream tracing with digitized direction. If you want to have attribution about tributaries, lift zones, etc you'll need to manage these using other means, since you won't have subnetworks to update. You also won't be able to use the IsConnected trace to identify disconnected elements, since it relies on traversabilty to subnetwork controllers. If you set up your treatment plant as a controller you'd be able to get most of this, you just wouldn't have the granularity to trace all of your sub-basins or any of the discharges downstream of your treatment plant (with subnetworks).

2a - Can you explain your use case around an isolation trace in a sewer system? Are you looking to isolate a pipe from its sink (i.e. simulating a blockage) or are you trying to determine how to place upstream barriers to isolate the area from upstream flow?

[NathanHeickLACSD]

Thanks Robert!  This really starts to lay down your options and decisions.  I was not expecting that connected traces used subnetwork controllers.  I need to see how using sinks compares to digitized direction.  I imagine that the worst case scenario would be that some pipes would be marked as indeterminate even though the pipe slopes in a certain direction.  Is the algorithm in the geometric network for setting flow direction similar to the UN?

Yes, I understand the concept of an isolation trace in water, but I was wondering how it actually worked and how it might be applicable to sewer systems.  One use case for us would be how do you divert flow around an SSO.  We can figure those things out manually with good data and symbology.  However, a flow trace that told you where to place a stop log to isolate an area would be more expedient in an emergency just like water crews trying to figure out which valves to close.  If we were using digitized direction, it would come down to what isolation devices, in this case stop logs, would block (redirect) flow from reaching the problem area.  We have more needs than this.  We need ways to design, track, and share flow diversions across the organization and integrate them into the work management system.  We've been gathering requirements internally and I've been trying to think of an information model for representing flow diversions.  Some of the flow diversions may be partial.  Some of them may be complete.  They all involve some upstream device(s) redirecting flow and they impact some set of downstream features.  Diversions are used to reduce flow to treatment plants for maintenance, pipes for construction, or manholes that are overflowing.  There are  scheduling component, data editing, design, and sharing components.

I would be interested in talking about this more in the future.  I imagine that the power of the UN trace tool could lead to custom geoprocessing tools that can perform more advanced logic through multiple traces combined, that is if it you can't do it with one trace.

It would be nice if there is a chart or a blog showing which traces have multiple passes, what each pass does, and which traces use subnetwork controllers.  I will try to do my own research.  The concept is a little bit hidden at first when you are learning the UN.  It's really important with the filter barriers.  It would be nice if that was more explicitly discussed.

[RobertKrisher]

@NathanHeickLACSD You will find these discussions in the intro and advanced sessions for the UN that we have at conferences, and you can find an article explicitly about the usage of filters here: Isolating failures using ArcGIS Utility Network