Scenario Input Sets

Scenario input sets allow you to easily keep model structure, while switching between groups of input data and parameters. These may be used to represent changeable physical attributes, such as climate, land use decisions or even proposed infrastructure characteristics. You can switch between different scenario input sets to compare the effects on a model. For example, you can have one scenario input set consisting of rainfall, inflow and evapotranspiration data for natural conditions, another for wet conditions and a third set for dry conditions.

You choose the scenario input set used for a run using the Scenario Input Set drop-down menu in the Configure dialog (Figure 1), accessed by clicking Configure on the simulation toolbar.

Figure 1. Configure, choose scenario input set. 

Scenario input sets are created and managed using the Scenario Input Sets dialog, which is accessible via Edit » Scenario Input Sets... (Figure 2).

Using the panel on the left, then right-clicking, you can do the following using the contextual menus:

• Add Scenario Input Set – create new scenario input set;
• Set Default – select this scenario input set to be the default;
• Add Child Scenario Input Set – create a new child scenario input set.
  
• Rename – change the name of a scenario input set; and
• Delete – remove a scenario input set.

Scenario input sets can define both input parameters and data sources. Input parameters specific to a scenario are defined in the Scenario Input Set dialog, either manually or using a file (see below). Data sources are assigned to scenario input sets using the Load Data Source dialog, as explained here.

Figure 2. Scenario input sets, parameter entry

Input parameter entry

Parameters specific to a scenario input set are defined and managed using the parameter set editor in the Scenario Input Sets dialog (as shown in Figure 1). The panel on the right allows you to specify parameters, either manually, or by loading a text file.

The general format for a parameter is: path1.path2...pathN=value (eg. Nodes.Inflow1.Flow=10 ML/d).

Manual entry

Figure 1 shows an example of manual parameter entry using the manual parameter set editor. This editor has the following features:

• An auto-complete functionality that is activated when an accepted scenario base node is entered for the first element of the path;
• Typing additional characters filters the auto-completion list. Pressing Tab or Return auto-fills an element from the auto-completion list;
• Pressing the period character ('.') displays a list of valid elements for the next step in the path;
• For a valid path, pressing the equals character ('=') displays candidate values;
• Click the Insert units icon for a list of available units. Note that these are not scenario-dependent so you must choose the correct item; and
• An invalid parameter is identified with an underline (illustrated in Figure 2 for the Loss 3 node, which was deleted after the parameter was created). Acceptable parameter types are provided in Table 1;

Table 1. Types of parameter values

File-based parameter specification

The file-based parameter entry (shown in Figure 2) allows the specification of a file that will contain the element path and values. The formatting of this file must adhere to the same rules as the manual parameter set editor.

Note that the Reload on Run and Relative path checkboxes follows the same rules as for data sources.

Figure 3. Input parameter set using a file

Child Scenario Input Sets

Child scenario input sets allow you to further refine model structure. A child scenario input set inherits all parameters and data sources specified in its parent. You can then set additional parameters, or alter existing ones. When you choose to run a model with the child scenario input set, the parameters from the child will take precedence over the parameters from the parent.

, because parameters in the child take The child inherits parameter changes in the child take precedence o A child input set inherits all parameters from its parent, and allows you to set additional parameters, taking precedence over parameters from the parent. 

Testing correct results:
1. Can't delete the last input set. ("Can't delete last")
2. Child can have same name as parent. ("Can have same name as parent")
3. Child can have same name as other children in other branches. ("Can have same name as other branches")
4. Child can't have same name as another child in the same branch. ("Can't name same as in branch")
5. Deleting a parent also deletes the children. ("Before parent delete" + "After parent delete")
6. Only root level input sets can specify datasources. ("Parent only datasource")
7. Root level input set affecting nodes works correctly and does not affect the GUI. ("Deactivate Inflow 100MLd IS") With the left inflow deactivated, only the right inflow reaches the confluence. ("Result - Deactivate Inflow 100MLd IS")
8. Child input set affecting nodes inherits it's parents changes correctly and does not affect the GUI. ("Deactivate Inflow 200MLd IS") With both inflows deactivated (one by the child and one by the child inheriting from the parent), no flow reaches the confluence. ("Result - Deactivate Inflow 200MLd IS")
9. Closing and saving the project, then reopening source does not cause any issues and everything is persistent.