Select to view content in your preferred language

A few Subnetwork questions

444
11
Jump to solution
a month ago
LiliYu2
New Contributor II

Hello - 

I start exploring Utility Network Subnetwork for Gas pipe recently and have a few entry level questions. I seem cannot find the answer here or maybe I didn't use right keywords to search on forum. Hope someone can help or direct me to the right place. 

Background: UN 6.0/Pro 3.1.2

  1. When creating pressure subnet and setting up terminal connections on the lines that are on each side of regulator, which is subnet controller, is the digitized direction of lines important to control how subnet is built. Ideally, gas flow from transmission pipe to distribution pipe via regulator (high pressure to low pressure). But I have transmission line digitized away from distribution pipe, while Distribution pipe is digitized toward Transmission (see screenshot below). In that case, I was wondering if gas pressure subnet can be built correctly? Or should flip the lines to simulate real world situation? 

LiliYu2_0-1715883593714.png

 

  1. Isolation Zone v.s. Isolation Trace. I've seen a few discussions about Isolation Trace along with case scenarios. But I don't see quite a lot about Isolation zone (Or Isolation subnetwork). I was wondering what's the purpose to have Isolation zone, and if there are any different practical examples than what isolation trace can do. 
  2. Clarification on Tier Rank - In the UN package I started with, System is defined Tier Rank 1, Pressure is Tier Rank 2, Isolation is Tier Rank 3. I am not so clear on how tier rank works, especially when building subnet. Does that mean system subnet needs to be built first (made to the database), then we can create pressure subnet on top of system subnet next; Once pressure subnet is made to the database, isolation subnet can be built after? I am able to create different tiers subnet without each other and wonder if that's wrong approach. 
  3. How to set up a subnetwork controller that can create a pressure subnet line that stops at where pressure change. Is disconnecting lines from each other the only option? 

Any input is appreciated. 

Thanks,

Lili

0 Kudos
1 Solution

Accepted Solutions
RobertKrisher
Esri Regular Contributor

I recommend you check out the Learning ArcGIS Utility Network for Gas and Pipeline to become more familiar with the model. You'll find some good tutorials specific to subnetworks in the Subnetwork learning series on that page. I'm also going to shout out @TomDeWitte since he knows the gas and pipeline industry and model much better than I could ever aspire to.

  1. The digitized direction of the line does not matter. It would be unfortunate if it did because some pressure zones within a distribution system can be bi-directional.
  2. You can always run an isolation trace by using a filter function barrier to define criteria for isolation. Creating and managing isolation zones is for when your organization has an explicit set of valves, features, and named zones that they track and manage. Managing isolation zone subnetworks is a lot more work, but it would allow you to see when installing new equipment or modifying equipment in the field would cause two existing isolation zones to become connected. Managing explicit isolation zones also allows you to quickly see and report the number of customers, valves, amount of pipe in each zone.
  3. In a source-based system like gas/pipeline tier 1 is the "ultimate source" to its the most upstream point in your network. While it makes sense you would want to model your systems before your pressure zones and pressure zones before isolation zones, the utility network does not require you to do this. Take the approach that makes the most sense for your business and requirements.
  4. I'm going to assume you're talking about validating the designed/set pressure for the pressure zone. Its technically possible to do this, but there are some undesirable side effects if you were to implement it. Instead of stopping at the location where the pressure rating is no longer adequate, but leaving it connected, wouldn't it be better to identify these features as part of quality assurance and determine why there are features inside your pressure zone that aren't properly rated?

View solution in original post

11 Replies
RobertKrisher
Esri Regular Contributor

I recommend you check out the Learning ArcGIS Utility Network for Gas and Pipeline to become more familiar with the model. You'll find some good tutorials specific to subnetworks in the Subnetwork learning series on that page. I'm also going to shout out @TomDeWitte since he knows the gas and pipeline industry and model much better than I could ever aspire to.

  1. The digitized direction of the line does not matter. It would be unfortunate if it did because some pressure zones within a distribution system can be bi-directional.
  2. You can always run an isolation trace by using a filter function barrier to define criteria for isolation. Creating and managing isolation zones is for when your organization has an explicit set of valves, features, and named zones that they track and manage. Managing isolation zone subnetworks is a lot more work, but it would allow you to see when installing new equipment or modifying equipment in the field would cause two existing isolation zones to become connected. Managing explicit isolation zones also allows you to quickly see and report the number of customers, valves, amount of pipe in each zone.
  3. In a source-based system like gas/pipeline tier 1 is the "ultimate source" to its the most upstream point in your network. While it makes sense you would want to model your systems before your pressure zones and pressure zones before isolation zones, the utility network does not require you to do this. Take the approach that makes the most sense for your business and requirements.
  4. I'm going to assume you're talking about validating the designed/set pressure for the pressure zone. Its technically possible to do this, but there are some undesirable side effects if you were to implement it. Instead of stopping at the location where the pressure rating is no longer adequate, but leaving it connected, wouldn't it be better to identify these features as part of quality assurance and determine why there are features inside your pressure zone that aren't properly rated?
LiliYu2
New Contributor II

Thanks @RobertKrisher for quick response! The link you shared is great tutorial to learn about utility network. It comes with the data error free and works great. It helps me a lot. But when I try the same steps with my own data (new to UN, not topology error free yet), there is always an issue (either tool failed, or subnetwork created is not expected). Lot times I chase down for the root cause but can’t seem to find good answer, so I asked my questions here.
Thanks for your response. I have following questions on Q1 and Q4.
1. Yes. There could be gas flow bidirectional on the pipe somewhere. But the question I had was more about the lines connecting to subnetwork controller via terminal, since the terminal configuration on the regulator (as subnet controller) is defined as directional, and gas flows from transmission to distribution and it is one-way flow. In this situation, if digitized direction of the line matters when building subnet.


4. I am sorry I didn't explain my question well. I was looking at Naperville pipeline sample data from ESRI. Take below as example, my question was, what to make west Pressure Subnetline (yellow highlighted, 425 psi) stops at where it meets Aurora Pressure Subnetline (Cyan color 275 psi) although there is connection between two pipelines? If I run Update Subnetwork GP tool with my own data, the pressure subnetline would run through without stop. I must physically disconnect two lines from each other to make subnet line stop. But looking at Naperville data, there is no physical gap or anything at connection, but subnet line stops. That confused me.

LiliYu2_1-1716217444502.png

 

 

0 Kudos
RobertKrisher
Esri Regular Contributor

1. Digitized direction does not impact subnetworks or the calculation of upstream/downstream. The only time the digitized direction of a line comes into play is when the "Use Digitized Direction" option is used to perform an upstream or downstream trace to use line direction instead of subnetwork. This option is not available for subnetworks.

4. Both pressure regulators are defined as subnetwork controllers for the 275 psi pressure zone (two controllers, one subnetwork), and the each of the lines are connected to the appropriate high pressure/low pressure terminals on the regulators. When the 275 psi pressure zone is traced, it knows to stop at those regulators. When the 425 psi pressure zone is traced, it sees that the regulators are regulating a pressure zone on their downstream terminals so it knows to stop.

LiliYu2
New Contributor II

@RobertKrisher Thanks for the confirmed answer !!

Q4, It is Controllable Valve not regulator. There isn't a subnet work controller here. 

CV's device status is closed, Tracing subnetwork would stop because it's a conditional barrier. But why the pressure subnet line created by updating subnetwork GP tool stops here...

LiliYu2_0-1716218550899.png

 

0 Kudos
RobertKrisher
Esri Regular Contributor

edit: added graphic

RobertKrisher_0-1716219829863.png

 

Ooooh it's a controllable valve. I'm not sure I understand your question, but I'll try to answer anyways.

The subnetwork line is created using the line features that represent that subnetwork (typically mains in a gas network). In your example, the valve causes the subnetwork trace to stop on the southern run and the compressor on the northern run acts as I described above. Because the lines on the other side of that valve aren't part of that subnetwork they aren't included in the subnetwork line for 425. They are, however, included in the subnetwork line for 275 pressure zone.

LiliYu2
New Contributor II

Thanks. I wasn't looking at Trace. Trace subnetwork stops at CV I understood.

I am looking at how that subnet line is created at first place and why it stops. Subnet line was created by update subnet line geoprocessing tool and it doesn't look at conditional barrier but still stops..In my own data, the subnet line wouldn't stop at CV but continue on. I am trying to compare with Naperville data for any difference.  

0 Kudos
LiliYu2
New Contributor II

ahh, I am sorry. There IS compressor (subnetwork controller) in the north area. That makes sense to have subnetwork line stops here. 

So the subnet line in the south still stops at CV, what to make it stops? 

0 Kudos
RobertKrisher
Esri Regular Contributor

Update subnetwork performs a subnetwork trace using the trace configuration included in the subnetwork definition for the tier of the subnetwork being updated. The subnetwork definition for pressure zones is that they have a condition barrier that stops at closed valves (among other things), so the subnetwork trace is performed using those condition barriers and the update subnetwork tool updates the subnetwork line and subnetwork name field to match the results of that trace. 

0 Kudos
LiliYu2
New Contributor II

I thought update subnetwork GP tool would look at Conditional Barrier set in subnet definition. But in my data, it continues on a closed device without stopping, so I looked further why subnet line stops in Naperville at CV but mine doesn't, then I looked how update subnetwork geoprocessing tool works in detail, top is the tool interface, bottom is the tool parameters behind the scene and it appears that conditional barrier is not considered by default. If that's true, why pressure subnet line could stops at CV in Naperville. I am not talking about trace, I am looking at the result from Update Subnet tool, which is how subnet line created in Naperville, I am assuming Naperville uses this tool to create Pressure Subnet Line. 

LiliYu2_0-1716221973238.png

 

arcpy.un.UpdateSubnetwork(
in_utility_network="Gas_UN Utility Network",
domain_network="Pipeline",
tier="Pressure",
all_subnetworks_in_tier="SPECIFIC_SUBNETWORK",
subnetwork_name="WOR-TEX",
continue_on_failure="STOP_ON_FAILURE",
condition_barriers=None,
function_barriers=None,
include_barriers="INCLUDE_BARRIERS",
traversability_scope="BOTH_JUNCTIONS_AND_EDGES",
propagators=None
)

0 Kudos