Tracing flow into multiple subnetwork controllers

[GaneshPremakumar]

Hello, I have a utility network that models flow into sinks, and my use case scenario is one where the flow into two subnetwork controllers is expected (i.e there is not just one sink but there are two) and when we perform a trace, we would like the trace to highlight paths into both controllers. 

I'll use the image below to illustrate this.

As seen above, there are cases where we would like the trace to flow into both subnetwork controllers and both paths should be highlighted when performing tracing. However, when we perform a trace, the trace fails as there are multiple subnetwork controllers detected. 

Are there any solutions for the trace to work in this way?

[MikeMillerGIS]

If they are controllers of the same subnetwork, it should not be an issue.  I am assuming you made them controllers of different subnetworks?

[GaneshPremakumar]

Yes, we want them to be part of separate subnetworks.

[RobertKrisher]

You can accomplish this by giving the two subnetwork controllers the same subnetwork name. While you can do this with any subnetwork, the most common workflows are below:

In a stormwater system, an entire neighborhood may have a single watershed that can be discharged through several different outfalls. Each outfall would have a unique subnetwork controller name, but they all would have the name of the watershed as their subnetwork name.

Pressure zones (gas or water) usually have multiple pressure regulating devices that help sustain and regulate pressure within an area. Each of these devices has its own unique name, but they all share the name of the pressure zone they are regulating.

[GaneshPremakumar]

Is it possible for this to work if the two subnetwork controllers control different subnetworks? If the subnetworks are different, the subnetwork names cannot be the same right?

[RobertKrisher]

@GaneshPremakumar if the two subnetworks are different, then they cannot be connected to each other. You'll need to find out why they are connected and correct your data so they are no longer connected. In the case of a gravity-based systems you may need to set up directional manhole channels or identify which pipes are only used in overflow scenarios.

In the above scenario the manhole where the flow diverges needs to be a directional manhole channel that defines which pipes are upstream, downstream, and which pipes have mutually exclusive flow. I discuss some techniques for troubleshooting tracing issues in gravity systems here: Stormwater Network Data Quality Assurance. The article is written for stormwater, but is readily applicable to most gravity systems.

Remember that even while you're working on getting your subnetworks dialed in, you can still use the digitize direction trace to do upstream/downstream tracing.

[GaneshPremakumar]

Thank you for your response. Could I check with you where I could find resources to read more about directional manhole channels? Currently, I am unfamiliar with these and how they can be used as subnetwork controllers. Thanks!

[PatrickGCowan · Accepted solution]

We are working on publishing detailed information about components for the foundations such as directional manholes. Keep an eye out for those in a future release. In the meantime, here is some basic information about directional manholes and how they are intended to be used.

Directional manholes are required in the Sewer UN Foundation anywhere you need to control flow or define subnetwork controllers for the Sewershed tier. Controllers must have multiple terminals, which is why a standard manhole structure isn’t sufficient.

They’re typically used for:

• Directional flow control to constrain flow and avoid loops
• Multiple internal channels where different channels flow to different downstream paths
• Sewershed definition, where sewersheds can be defined using the terminals

A directional manhole has two upstream and two downstream terminals, and a single manhole can act as a controller multiple subnetworks. Flow through the manhole is governed by valid paths, which define how terminals are allowed to connect and represent the internal channel configuration.

The diagrams below show the valid path configurations.

[GaneshPremakumar]

Hi Patrick, how would these enable us to allow flow into two different subnetworks (the inverse Y Junction as seen in our diagram)?. In our use case, our subnetwork controllers do have multiple terminals, and the valid paths have been defined as well. Thanks!

[RobertKrisher]

@GaneshPremakumar the subnetwork controllers stay as is, but the manhole where these two subnetworks comes together will have this terminal configuration. The path for each subnetwork will be assigned to a different downstream terminal and you will use the "up to down" terminal path. This lets the system know that subnetworks 1 and 2 represent mutually exclusive downstream paths in the network (which fixes the inconsistent subnetwork name error) while still allowing the area upstream of the manhole to belong to both subnetworks.

If the area upstream of the manhole should only belong to one of the subnetworks, with the second subnetwork only be accessible during high volume events, you would take a different approach that defines one the paths as only valid during high volumes.