topic Re: Isolation trace - Simulate whatifs scenarios in ArcGIS Utility Network Questions

Isolation trace - Simulate whatifs scenarios

khem1000 — Fri, 06 Mar 2026 23:26:19 GMT

Hi, we have a custom Experience Builder app with the OOB trace UM widget various configured named traces built in Arcgis 11.5.

This includes the a valve isolation Trace in the water network, which returns the list of valves to close and list of impacted properties if a section of mains is isolated.

We now have a business requirement to enable users to simulate opening one or more nearby valves that would allow water to be fed from a different DMA so as to reduce the number of impacted properties in the event of a burst.

Thinking we may need to call a GP service which 1) identifies the valves which beëong to neighboring DMAs. If these are closed, then 2) change their status to open in a version 3) perform an isolation trace 4) return to user list of valves they can potentially open and corresponding list of impacted properties

Any ideas on the above requirements

Thank you

Re: Isolation trace - Simulate whatifs scenarios

RobertKrisher — Sat, 07 Mar 2026 14:57:28 GMT

Because you are opening the valve, that will only work if the area being analyzed is all within the same subnetwork (pressure zone or subnetwork). Another approach you could take, that allows you to operate across multiple subnetworks AND doesn't require you to edit the data, is to place additional starting locations on the other side of the valve you want to simulate as open.

Re: Isolation trace - Simulate whatifs scenarios

PierreloupDucroix — Mon, 09 Mar 2026 02:40:48 GMT

Hello, I'm currently having the same thought process regarding opening closed valves to mitigate the impact of water outages.

Robert's proposed solution works best when the user needs to mark a valve as "inaccessible" or "unoperable." It's then possible to extend the isolation to the other side to simulate ignoring the valve. Even better, it's possible to add a starting point directly on the valve and specify the "Ignore barriers at starting points" option in the trace configuration.

Regarding opening a closed valve, it's not possible to force this object to be ignored as a barrier, since it's part of the trace's traversability parameters.

A simple solution I've considered is to temporarily modify the traversability during the trace to ignore closed valves. Using the Water Distribution UN Foundation dataset as an example, you can remove the conditional barrier "P:Device Status" = Closed. This way, closed valves will be considered open to supply a portion of the network, and previous valves on the network will be detected by the isolation trace.

However, there are drawbacks:

- The user doesn't explicitly choose which closed valve to reopen. However, they can explicitly designate a valve to remain closed by setting a break point on the map and specifying that it's a filter barrier.

- For the isolation trace to work, it needs to detect a subnet controller within a single subnet. Therefore, tracing must be done at the highest level (i.e., Water System); otherwise, more than one subnet may be detected.

- In reality, this will only work if you have sufficient pressure, so more tests would be needed to ensure that the pressure subnetwork on the other side of the closed valve is higher than the one being shut off...

Example, here a "normal" isolation trace in the Water Pressure tier, that finds closed valves (north) :

normal trace

And here is the same, at the Water System tier, without the Device Status barrier. The first open valve is detected instead of the closed one, a portion of the outage zone is now unimpacted :

New trace without closed valves

I am open to discussing this further if other solutions are being considered.

Re: Isolation trace - Simulate whatifs scenarios

Jens_Dalsgaard — Mon, 09 Mar 2026 18:49:31 GMT

This might be easier to reach once Esri delivers on the long awaited (but not short-term committed) 'trace override'.

At least the way I understood this - as a way to have traces use switching statuses registered in a UN-external table instead of the switching status registered on the valve / switch.

Re: Isolation trace - Simulate whatifs scenarios

RobertKrisher — Mon, 09 Mar 2026 19:06:35 GMT

@Jens_Dalsgaard you'll still have the problem with inconsistent subnetwork names.