We are trying to understand which terminals will be valid options when setting a device as a new subnetwork controller in different situations.
In particular how this is affected by:
Our current understanding is that:
In Partitioned Networks:
In Hierarchical Networks:
Clarification needed:
Our confusion surrounds hierarchical tiers and subnetwork controllers with directional terminals.
Is there a restriction on which terminal (upstream vs downstream) can be a controller in this case?
The documentation says:
Flow direction for the entire subnetwork is determined by the subnetwork controller type (source or sink) set for a domain network. Subnetwork controllers set on terminals designated as downstream (according to the terminal configuration) behave as sources in a source-based network. Subnetwork controllers set on terminals designated as upstream behave as sinks in a sink-based network. To learn more, see Subnetwork controllers.
The wording in the documentation is a bit confusing. It seems to imply that a sink-based network would always result in only upstream terminals in directional terminals being valid options for setting a new controller .
However, testing in ArcGIS Pro with the Water UN Sample, with a hierarchical tier and directional terminals, I am seeing no restriction on which terminal (upstream/downstream) can be set as a subnetwork controller on an asset with a directional terminal:
e.g. This Pressure Valve - Pressure Reducing
All this seems to imply that in a hierarchical tier (and sink-based network) it is possible for a downstream terminal to act as a sink (and vice-versa for a source-based network).
Solved! Go to Solution.
My understanding (after testing different scenarios and not by the documentation) is any terminal can be a subnetwork controller in a "hierarchical network". You do not get a choice. And I think this is a correct behavior, otherwise it will be almost impossible to build an "isolation tier" or a "shut-off block" for a mesh water network.
In a "source" based "partitioned network", only "downstream" terminal can be a subnetwork controller. In a "sink" based "partitioned network", only "upstream" terminal can be a subnetwork controller. This is baked into the UN topology.
In your case of Pressure Reducing Valve (PRV), you will need to define the terminal path to be only "Hi-Pressure" to "Low-Pressure" and not vice-versa. Then, if you specify "Low-Pressure" terminal as a subnetwork controller, the subnetwork build will follow the pipe at that terminal and not the pipe connected to "High-Pressure" terminal, because there is no path from Low-Pressure to High-Pressure.
User can accidentally choose "High-Pressure" terminal of a PRV to be a subnetwork controller. System cannot stop it. But during the subnetwork build, you are likely to reach another subnetwork controller that has different subnetwork name and it will lead to an error.
Cheers,
Vish
My understanding (after testing different scenarios and not by the documentation) is any terminal can be a subnetwork controller in a "hierarchical network". You do not get a choice. And I think this is a correct behavior, otherwise it will be almost impossible to build an "isolation tier" or a "shut-off block" for a mesh water network.
In a "source" based "partitioned network", only "downstream" terminal can be a subnetwork controller. In a "sink" based "partitioned network", only "upstream" terminal can be a subnetwork controller. This is baked into the UN topology.
In your case of Pressure Reducing Valve (PRV), you will need to define the terminal path to be only "Hi-Pressure" to "Low-Pressure" and not vice-versa. Then, if you specify "Low-Pressure" terminal as a subnetwork controller, the subnetwork build will follow the pipe at that terminal and not the pipe connected to "High-Pressure" terminal, because there is no path from Low-Pressure to High-Pressure.
User can accidentally choose "High-Pressure" terminal of a PRV to be a subnetwork controller. System cannot stop it. But during the subnetwork build, you are likely to reach another subnetwork controller that has different subnetwork name and it will lead to an error.
Cheers,
Vish
Hi @VishApte, thank you for taking the time for such a detailed response. I have a few follow-up questions based on your answer- I hope that is okay.
In your case of Pressure Reducing Valve (PRV), you will need to define the terminal path to be only "Hi-Pressure" to "Low-Pressure" and not vice-versa. Then, if you specify "Low-Pressure" terminal as a subnetwork controller, the subnetwork build will follow the pipe at that terminal and not the pipe connected to "High-Pressure" terminal, because there is no path from Low-Pressure to High-Pressure.
I'm a bit confused about the above section of your reply.
The documentation seems to imply that restricting valid terminal configuration paths to a single direction is not possible. i.e. the path concept is expressed as pairs without a direction (see docs below).
Are you referring to fact that the directionality of the terminal configuration would be blocking flow in one of the directions (i.e. upstream to downstream)?
https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/about-terminal-management.htm
"If only two terminals are specified, there is no need to set valid paths, because there is only one. Valid paths can be a terminal pair (single path), a collection of terminal pairs, all paths, or no paths. A terminal pair denotes a single path in which a commodity can travel. For example, A-B states the resource can flow in through A and out through B or in through B and out through A."
When you define a terminal configuration, specify "Pressure Reducing" configuration as a "Directional". Asset Package table entry looks like below:
Then when you assign terminals to that Terminal configuration, specify one of the terminal as Upstream. Asset Package table view as below.
And you do not need to specify any paths. Default All paths is ok. But above two table records mean that water can only flow from "High Pressure In" terminal to "Low Pressure Out" terminal. Final Topology property looks like below:
Hope this helps.