Subnetwork Errors
In our previous blog, we discussed how subnetworks are used in the Water Distribution Utility Network Foundation and how you can create them. In this blog we will talk about how to maintain subnetworks and what to do if you run into a subnetwork error when validating your network using the Update Subnetwork tool.
Every time the features in a subnetwork are modified and validated, the subnetwork is marked as dirty. The Update Subnetwork tool is used to validate the integrity of the subnetwork and populate the subnetwork name field on features in your subnetwork. You can learn more about the update subnetwork process in the Update a subnetwork page in the online help.
If the tool finds one or more problems with your subnetwork it will create error features in your database, often referred to as subnetwork errors. You can read more about subnetwork errors in the subnetwork error section of the Errors topic in the online help. The purpose of blog post is to describe the most common subnetwork errors and their resolutions.
Below you will find examples of errors with the most common error codes and their resolutions. The error types listed in the table above are shorthand descriptions for the error code that users typically use when discussing these types of errors.
| Error Type | Error Description | Resolutions |
| Invalid Equipment | *26 – Invalid device feature was discovered during update subnetwork.
* This error has multiple error codes depending on the layer involved 24, 26, 40, 41, 42. These codes correspond to lines, devices, junctions, junction objects, and edge objects. |
1. If the affected features have been drawn correctly and should be allowed to participate in this tier of the network, then your geodatabase administrator can update your subnetwork definition to allow them to participate in this tier.
2. If you determine that the features have an incorrect asset group/asset type, then you should correct their classification. 3. If the features are correctly classified and should not participate in this tier, then you will need to correct your data to prevent them from participating in this tier. |
| Inconsistent Network Controller | 29 – Inconsistent subnetwork name on multiple subnetwork controllers in the same subnetwork discovered during update subnetwork. | 1. If the features connected to each controller should be a single subnetwork, you should update the subnetwork names associated with each controller to match.
2. If the features connected to each controller are different subnetworks and should be isolated from each other, you will need to determine why they are connected and update your data so they are isolated. 3. If only one of the controllers is active but have different names, then you will need to either isolate the backup controller from the active controller or remove the subnetwork controller assignment from the backup controller. |
Invalid Equipment
Update subnetwork definition
In the image below there is a well connected directly to a pressure system. Because wells exist only in the system tier in this configuration, they aren’t allowed to be part of a pressure zone.
If we don’t want to model the pumps that pump the well water out and provide pressure, we can update the subnetwork definition to allow wells to participate in the pressure system.
This will resolve the error, but when performing pressure traces the well will not be considered a pressure source.
Correct the classification
The next error is similar to the above—we have a well directly connected to the pressure system.
After some investigation, we determine that the device is actually a storage tower and not a well. This issue was caused as a result of a migration error. In our previous system, wells and storage tanks were maintained in the same layer. To correct this issue and make the error feature go away, we perform the following:
- Update the well with the correct asset group and asset type
- Validate the topology for the device and line
- Run Update Subnetwork
Because a storage tank can be a pressure system controller, there is also a strong chance that we need to create this storage tank as a subnetwork controller for this pressure system. You would want to confirm this with an engineer or someone who is familiar with this pressure zone before making this change.
Isolate the equipment
In the following example, once again there is a well connected directly to the pressure system.
To model the pumps that are responsible for extracting water from the well, perform the following steps:
- Identify the name and location of the pump(s)
- If modelling multiple pumps, you can create additional pipes and valves to precisely model the system
- To model the pumps more simply, you can represent them using a single pump station feature
- Regardless of the approach you take, you will need to connect the terminals of the pump to the pipes on either side of it
- Set the pump feature as a subnetwork controller, creating an additional controller for the pressure system.
- Validate the network topology for the area.
- Run update subnetwork on the pressure zone subnetwork to include the new controller.
- Run update subnetwork on the water system subnetwork to include the well.
Creating the pump station or pumps as subnetwork controllers for the pressure system will resolve the error and correct the model for the water and pressure supplies in our network.
Inconsistent Network Name
Update subnetwork name
In the example below, three storage tanks outside the water treatment plant are providing pressure to the same zone. During subnetwork creation we named each pressure zone using the name of the tower or tank. This resulted in errors when we ran the Update Subnetwork tool.
After discussing the situation with members of our engineering group, they let us know that this entire area is a single pressure zone and provided the correct name for the pressure zone. Use the Modify Subnetwork Controller pane to re-create the subnetworks, giving each controller a unique name but with all the controllers referencing the same pressure zone. After correcting the name, validate the controllers to reset the errors and update the subnetworks.
Isolate the networks
If you receive the Isolate the networks error and the two subnetworks in question should not be connected, then you have a feature that is improperly snapped or an open valve that should be closed.
To identify where the problem is, run a shortest path trace between the two controllers, setting a condition barrier for closed equipment.
You will then review that path until you can find the location where you need to disconnect a piece of equipment or close a valve. If you have a pressure zone polygon layer or legacy pressure zone field that was created before your conversion, it will make this process much easier.
After reviewing system records, it was determined that a main was cut, capped, and abandoned, but the GIS was not updated. Once the GIS is updated, run the Update Subnetwork tool to validate the subnetworks.
Next Time
In addition to identifying errors using the Update Subnetwork tool, there are other checks that customers may perform as part of their quality assurance program to ensure their subnetworks are valid. These situations aren’t considered errors because there are often times when they are acceptable, so they shouldn’t prevent users from completing their work or analyzing data in the system.
In our next blog, we will share some of the most common quality assurance techniques that can be used inside ArcGIS Pro to find and review issues with your subnetworks.
Commenting is not enabled for this article.