Isolation Trace Returns Too Many Valves and Misses a Boundary Valve
A water transmission main breaks on a 16-inch line. The isolation trace is run from the break point to identify valves to close. The result lists 18 valves, but the field crew says only six boundary valves need closing. The extra valves are on the far side of a pressure-reducing valve (PRV) and on a parallel 8-inch bypass that is normally closed. One boundary valve is missing: a 12-inch butterfly valve with valve type 'system' and status 'open.' The utility network has valve asset types 'Isolation,' 'System,' and 'Blowoff.' The PRV is a device asset type 'PRV' with a terminal configuration and an open status. All features are in the same pressure subnetwork. The trace was run with default settings: include isolation valves, do not include barriers, and trace within the subnetwork.
1. Explain why the trace includes the PRV's far-side valves and the bypass valves. Which trace settings or network attributes would you change?
Read the worked answer
The default isolation trace expands until it encounters isolation valves. If the PRV is not configured as a barrier, the trace passes through it and continues to valves on the far side. The normally closed bypass valves may also be traversed if closed status is not being used as a stopping condition, so their associated valves appear in the result. The setting change is to define barriers: include the PRV asset type as a barrier and include closed valves, or specifically the closed bypass valves, as barriers. Also restrict the isolation-valve filter to the 'Isolation' asset type rather than accepting every valve asset type. That prevents system and blowoff valves from being returned as boundary valves. The expected result is a trace that stops at the six field-confirmed boundary valves, with the PRV and closed bypass acting as limits rather than pass-through points.
2. The missing butterfly valve is an open system valve. What checks would you perform before deciding it is a data error rather than a trace setting?
Read the worked answer
First check the trace's isolation-valve filter. If only the 'Isolation' asset type is included, a 'System' valve will not be returned even when it is the correct boundary. Next check whether the valve is actually on the trace path and has valid terminal connectivity; a missing terminal configuration or unvalidated dirty area can exclude it. Validate the network topology around the valve and confirm it is in the same subnetwork. Check for container or association behavior that might hide it. Also verify the valve status and the trace location, because a trace started on the wrong side of a fitting can change the boundary set. Only after those checks should you reclassify the valve. If field records confirm it is a boundary isolation valve, change its asset type or isolation attribute, then rerun the trace; do not reclassify all system valves just to make one result appear.
3. How would you verify the revised trace with the field crew and document the result?
Read the worked answer
Produce a closure list with valve IDs, asset types, locations, normal status, and the reason each is a boundary. Compare the six valves with the field crew's expected boundary and confirm accessibility. Rerun the trace with the PRV and closed bypass as barriers and with the isolation filter limited to true isolation valves. Check that the previously missing butterfly valve appears and that the far-side valves disappear. Save the trace configuration so the same logic can be reused. Document the assumptions: PRV is a barrier, closed bypass is a barrier, and the butterfly valve is an isolation boundary. If field review disagrees, fix the asset classification or network attributes and repeat the trace rather than manually deleting valves from the list.