Subnetwork Name Attribute does not populate.

[Paul_Lalancette]

I am currently configuring subnetworks in the stormwater model with the resulting subnetwork name attribute not populating in expected devices/lines after running "Update Subnetworks". 

Below are the steps I performed.

1. Created a valid subnetwork controller(Outlet, Pipe Outlet) and subnetwork using "Modify Controller". A new subnetwork was added to the subnetwork table.
2. Updated the Terminal Connection of the line connecting to the Controller as "Inlet Port" using the Terminal connections tool.
3. Validated the network using the network topology tool – resulting in no dirty errors
4. Ran the Update Subnetworks tool – resulting in a successful result. The subnetwork is not dirty.
5. Ran a Subnetwork Trace which was successful through the first orange line(see picture)

I reviewed the tier and all asset groups/types for devices and lines are members. I also updated the "Is connected" attribute to "True" using the "Update is Connected" tool.

Any ideas on why the remainder of my subnetwork is not updating the expected attribution?

[RobertKrisher]

@Paul_Lalancette is the subnetwork name populated on the device? if so, the device is acting as a barrier to the subnetwork. check its attributes and any terminal connections to determine why its stopping tracing (is it active? is it closed? does it have an activate volume?).

If the device isn't part of the subnetwork, then your culprit is likely the stormwater line itself. You'll want to look at the attributes and terminal connections of the line to see why its stopping the trace.

[Paul_Lalancette]

@RobertKrisher Thank you Robert for your helpful suggestions for troubleshooting my subnetwork attribute issue.

After reviewing your suggestions and reviewing the UN Network Properties I believe the tracing issue stems from missing expected "Valid Paths" in the Terminal Configurations (below). In the base stormwater solution, these values are set to "All [Default] None."

What is your recommended workflow for adding these missing values back to the terminal configurations?  I am working with Pro 2.9.8, UN Version 5. Thank you!

[RobertKrisher]

@Paul_Lalancette Curious, I didn't think you could create a terminal configuration without any valid paths, I'll put that on my list of things to try out tomorrow. You can't modify a terminal configuration once created, and you can't change an asset type's terminal configuration once it has had a configuration.

Unfortunately, this doesn't leave you with a lot of options, the easiest of which would be to export your utility network back to an asset package, put the appropriate configuration back into place in the asset package, and to re-deploy your utility network. It looks like you're still prototyping your utility network, so I hope this isn't too much of an inconvenience.

[CashEddy · Accepted solution]

Paul,

Your workflow looks correct. After testing this in a pilot area on a clean base model Solution, I was able to get a clean and traceable Subnetwork by doing the following after adding your new Subnetwork Controller and Terminal (Inlet Port):

1. Isolate an area to configure and save all edits
2. Set Subnetwork Controller & Terminal and Apply
3. Validate Network Topology (Entire Extent)
4. Update Subnetworks (All Subnetworks in Tier) - not just the target Subnetwork, given that changes are being made to other features in the UN data outside this subnetwork (break a line to cut out a pilot area, delete any feature necessary to disconnect and carve out an area-of-interest to test)

This should essentially validate all edits, and recalculate all the Subnetworks as changes were made to more than just features that participate in this new Subnetwork, if that makes sense.

Respectfully,

-Cash