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.
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?
Solved! Go to 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):
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
@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.
@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!
@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.
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):
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