Valid paths not routing upstream trace correctly through features in multiple subnetworks (Sewer Tee junction)

J_iaxin

Hi all,

We are currently facing the 001890 bug on invalid subnetwork connectivity. Following up on Tracing flow into multiple subnetwork controllers (similarly in Downstream Trace - Sewer Utility Network) and the guidance in that thread, we implemented the recommended valid paths approach on our directional manhole terminals, but the results do not match our expected results.

Context

We are implementing a gravity sewerage utility network. In several locations, a single manhole acts as a subnetwork controller where multiple subnetworks (with different subnetwork names) are topologically connected through the manhole, which reflects real flow/connectivity in the field.

An example in the network:

Prior guidance in the linked thread included:

1. Assign the same subnetwork name to controllers that should trace together — not applicable here; these are genuinely distinct subnetworks that must remain connected.
2. Break traversability between controllers — not acceptable for our use case; operations require the current connected topology.
3. Use a directional manhole with valid paths to control internal flow between terminals (upstream/downstream/crossover) 

We tested Point #3 with our Crossover valid path (instead of Normal [All]), which is similar to what was suggested to us:

Esri’s documented scenario (from the thread / product guidance) assumes a directional manhole with multiple upstream and downstream terminals (e.g. two upstream + two downstream). However, in our case, we only have 3 ports, where the flows separate downstream.

Observed results

After switching valid paths to Crossover (confirmed applied successfully on the terminal configuration):

1. Upstream trace from the manhole/controller area only consistently recognises one subnetwork side (Kranji in our test case, seen in the screenshot at the start).
2. Upstream trace for the other subnetwork (Changi) stops prematurely — it does not continue to the upstream sewer segment that is topologically part of both subnetworks through the manhole.
3. We attempted an alternative terminal assignment on the Changi subnet downstream sewer (Outflow 1 → Inflow 1). That change causes subnetwork validation failures because the subnetworks are no longer self-contained.

In our case where traversable controllers with different subnetwork names (001890 scenario) that must remain connected, is there a supported way to obtain correct upstream and downstream traces for both subnetworks through a shared manhole/terminal?

 

RobertKrisher

Met and discussed with @J_iaxin . The problem is that when you run a trace on a feature that belongs to multiple subnetworks the system returns an inconsistent subnetwork name error. In this case, a sub-basin has outlets to two different treatment plants so any traces within that sub-basin return this error.

I have asked the user to log an issue and escalate this as a bug. Each subnetwork is consistent, and just because this area can drain to different subnetwork controllers doesn't mean the trace should fail.