Utility Network Topology Errors from Subnetwork tier creation

Question

Background: ArcGIS Enterprise 11.1, ArcGIS Pro 3.1.7, Utility Network version 6, current UN wastewater schema based on Sewer Utility Network Foundation V1.1.

We've been in production for about 18 months.  Recently, I've been building out subnetwork tier groups and tiers to model out new subnetworks.  We are installing SmartCover devices in 35 manholes in our service area to model three things: RDII, Capacity Deficiencies, and one or more areas with high risk for overflows.

I started by creating two new tier groups: "Sewer Capacity Deficiency Metering Areas" and "Sewer RDII Metering Areas".  Within each tier group, I created 5 tiers (ranked 1 through 5) for a total of 10 new tiers.  The reason for the hierarchy is that (especially for RDII study areas) we install a SmartCover at the most downstream manhole of the study area, install 2-3 SmartCovers upstream on manholes on different branches off the main trunk, install 1-3 SmartCovers upstream of those manholes on smaller branches, and repeat as needed.  For each sewer main (and structure) that falls within our study areas we need to know which of the subnetworks (across all the tiers) they belong to.

The first time I re-enabled topology after creating the tier groups/tiers, every single SewerLine feature had a topology error (32: Error setting weight values . 32,[This weight cannot be null.]).  I researched that error, examined the network attributes and assignments, and nothing looked wrong. The one attribute that was possibly questionable was the "Cathodic Protection Traceability" attribute, which is assigned to the "cptraceability" field on SewerDevice (through the various subtypes).  That field contained all null values in my data.  The domain assigned to it from the Esri Solution was the "CP_Traceability" domain.  The "Cathodic Protection Traceability" attribute is configured to allow nulls, so this didn't seem like it should be a problem.

I looked at the data dictionary for the Sewer Utility Network Foundation V1.2 (https://solutions.arcgis.com/water/help/sewer-utility-network-foundation/DataDictionary/DataDictionary/ ) and found that the domain for the cptraceability field was changed to "Yes/No" which contains the values 0 through 2 (0 is Unknown, 1 is Yes, 2 is No).  On a hunch, I changed the domain assignment for the "cptraceability" field for the various SewerLine subtypes to use the "Yes/No" domain in my data. I ran Calculate Field to update the "cptraceability" values to 0 (zero) for all records.  When I re-validated my data, all of the topology errors went away.  It didn't really make sense to me why this was an issue, but I was happy that my data was working.

This past Friday I needed to add more tiers to the "Sewer RDII Metering Areas" tier group (I added them with ranks 6 through 10). I also created a new "Sewer Risk Monitoring Metering Areas" tier group and added 5 tiers (ranks 1-5) to it.

This morning, I discovered that all of my SewerLine features again are showing the same topology errors as before (32: Error setting weight values . 32,[This weight cannot be null.]).  There are no other attributes that are assigned to a SewerLine field that contain null values. Where is this error coming from now, and how can I fix it?

UN Attributes.PNG

CarlVon_Stetten1 · Answer

@RobertKrisher the attribute rules for Cathodic Protection Traceability have been disabled since we implemented the Utility Network in 2023.  I confirmed they are still disabled, so they are not altering the data in the cptraceability field.

rkrisher · Answer

@CarlVon_Stetten1 If you check the cp traceability field in your data again, has it become null again? There is an attribute rule that is responsible for calculating that value, and I suspect that when you're adding these tiers and their new fields, that the rule is being triggered when the subnetwork name is set to 'Unknown'.

The rule should return a 0, 1, or 2, but its possible with the modifications you've made to your model its returning a null value because something is exiting early.

CarlVon_Stetten1 · Answer

@RobertKrisher I logged a case as you suggested (https://my.esri.com/#/support/cases/tech-cases?caseNumber=03804481 ).

To be clear, that particular network attribute is set to allow nulls, and the fields are also set to be nullable.

The reason I made the change to the domain assignment is that the "CP_Traceability" domain previously assigned has only two states (yes/no), but I don't know what the correct value would be for our data.  I needed to be able to set the default and all of the existing records to Unknown, so I changed the domain assignment to what the more recent version of the Solution uses (the "Yes/No" domain).