Elements seemingly changing to default settings, zero status, inactive

  Product(s): WaterCAD, WaterGEMS, HAMMER, StormCAD, SewerCAD, SewerGEMS, CivilStorm, PondPack
  Version(s): 08.11.XX.XX and higher
  Area: Modeling

Problem

After reopening a model that was working well, elements appear to have lost data, such as:

  • "Is Active" set to "false", color gray, generating user notifications about pipes referencing a deleted or inactive node.
  • Properties such as elevation, Valve settings, etc set to zero, or certain other fields set to default such as 6 inch diameter for pipes
  • Pumps becoming disconnected from their adjacent node

Explanation

Assuming that the model was properly saved and that the correct model file was reopened, this is likely not a matter of losing data but rather due to how these elements were added in the model, with respect to the scenarios and alternatives. If the scenario that they were added to used child alternatives, then the information about those elements in any scenarios that use the parent alternative will use the default settings, since inheritance works the other way. Meaning, the program cannot assume what properties the new element should have (including whether it is active or inactive) to it uses the defaults. Consider the below example:

- There are two scenarios, base and child. The Base scenario uses the alternatives called "base" and the child uses the ones called "child".
- The model network is laid out while in the base scenario

Now, let's say you're working in the Child scenario and decide to insert a PRV into pipe P-6 (pipe split)

- The initial status of the PRV is entered, and therefore stored in the "child" Initial Settings alternative.

Everything appears to be fine, at least in the child scenario. However, if you now look back at the Base scenario (which again, uses the Base alternatives), there's a problem:

- The valve is inactive

- The pipes reference an inactive node

- The initial pressure setting, elevation, etc are all default / zero

The reason is because when a new element is added to the model, it exists in all scenarios/alternative and initially takes on default settings (zero elevation for a node, 6 inches diameter for a pipe, etc), or default settings set up in a Prototype. These default settings will initially be populated for that element in all alternatives (and for all scenarios.) The exception is Active Topology, where the default status for the "Is Active" property is "False" for all Active Topology alternatives except for the one that is used by the scenario that was active when the element was added (and any child alternatives if inheritance is not disabled in them.) The element's "is active" state will be set to "True" for the current scenario/alternative, which can be inherited by child active topology alternatives. The reason why parent active topology alternatives have a default status of "false" for "Is Active?" is because it is assumed that a child active topology alternative represents future conditions, and that the elements placed in the future conditions scenarios do not yet exist in the parent scenarios.

Therefore, that element will remain inactive in any parent active topology alternatives. Likewise for other properties, once they are changed in a given alternative, that change can be inherited by child alternatives, but the parent/base alternatives will still remain with their initial, default status.

This is why in the example above, the pressure setting was still zero in the base scenario and the "is active" status was "false".

To Avoid This...

To avoid this problem in the future, if you want to add an element that will exist in all scenarios, it's best to add that element while in a scenario that uses the base/parent alternatives. That way when you initially enter the attributes such as the elevation, setting, etc, those settings will be inherited by child alternatives and therefore will be seen in scenarios that use those child alternatives.

If you want to add elements that will only exist in child scenarios (for example a future expansion), add them while in the scenario that uses the child alternatives, but be aware of how that might effect the parent. For example if you added the new element by splitting a pipe, those new pipes will need to exist in the parent scenarios as well. So, if you want to add a new, proposed/future element that is in-line with an existing pipe for a future conditions scenario it might be best to add new parallel pipes connected to that element and set them to inactive in the existing conditions scenarios.

See Also

Scenario and Alternative Management

Active Topology Management

Is it possible to delete an element from one scenario, but retain it in another?

Recommended
Related