Scenario Inheritance
Scenario Manager will pass changes made in a scenario to linked attributes of its descendants, allowing multiple scenarios to be modified in one operation and maintain similarity between scenarios where desired.
Any attribute whose value is the same as that of the scenario’s parent is linked to the parent. In turn, if the parent’s attribute value is the same as that of its parent, then the child’s attribute is linked to its grandparent. This ancestral linking of attributes can exist across any number of generations. A change made to a scenario will be passed downward to its children, grandchildren, etc., as far as the link exists. Changes are NOT passed upward from child to parent.
Once an attribute is changed within a scenario, the link is broken to that individual attribute. Subsequent changes in the scenario’s ancestors, parent, grandparent, etc., will no longer affect that attribute, but all other attributes within the scenario will remain linked. The Model Data window with Ancestral Data enabled on the Scenario Format tab shows how the data changes between scenarios.
Scenario logic examples
For many users, it is easiest to grasp Scenario Manager when it is explained how the coding logic is actually implemented. Blank fields for children, grandchildren, etc., mean to look to the parent for the data. The Base Scenario never has blank fields (Figure 2). Data only passes downwards, never upwards.
Table 1: Blank fields for Child #1 and Grandchild #1 mean that the data is to come from the parent. If the Base scenario data is changed, all descendants are changed.
If a child scenario does not have a blank field, then data for that property is initiated at that scenario level (see Table 2).
Table 2: Child #1 does not have a blank field, so it’s Diameter would be 2, not 3, as would Grandchild #1
If a scenario is changed, and its child has different data, then the change will not pass downwards (see Table 3).
Table 3: Changing the Base Scenario Diameter from 3 to 6 would not impact Child #1 or any descendants in that line. Changing the Length from 25 to 40 would also change the length in Child #1, Grandchild #1, and any descendants of Grandchild #1.
If a child scenario has data that is different than the parent, its children cannot relink to the parent (see Table 4).
Table 4: Even if the Grandchild #1 has the same Diameter as the Base, it is not linked to the Base because it and its parent are not blank.
If a child scenario’s data, which was previously changed and is thus different from the parent, is changed back to the same vale as the parent, the inheritance link is re-established (see Table 5). Its descendant’s link is also re-established.
Table 5: If the Diameter in Child #1 is changed to be the same as the Base, it will be "blanked out" the next time the scenario is loaded and the link re-established. And so will Grandchild #1, if it’s Diameter is also the same.
Table 6 shows data for two pipe properties across three scenarios. The data that would be used when each scenario is loaded is as follows:
-
Base scenario
-
Diameter = 3
-
Length = 25
-
Changes to Diameter will not pass downwards
-
Changes to Length will affect only Child #1.
-
-
Child #1 scenario
-
Diameter = 2
-
Length = 25
-
Changes to Base Diameter will not affect Diameter
-
Changes to Base Length will affect Length
-
-
GrandChild #1 scenario
-
Diameter = 2
-
Length = 15
-
Changes to Base Diameter will not affect Diameter
-
Changes to Child #1 Diameter will affect Diameter
-
Changes to Base Length or Child #1 Length will not affect Length
-
Table 6: Input data for these properties explained in the text.
Re-Establishing Broken Scenario Links
A link may be re-established by returning the attribute to the same value as that of its parent. This can be done manually by entering the value or selecting the Copy Data From Pipe list and selecting the Parent Pipe Data option. Within other data windows, it is done by selecting the Same As Parent option in Analysis Setup, Output Control, Library Manager or Visual Report Control.
Since links are identified by comparing attribute values of pipes or junctions with the same Workspace ID number, renumbering a scenario will break the links of all pipes and junctions renumbered. Since numbers must be unique, once a link has been broken by renumbering, it may not be re-established.