ntroduction

Scenarios in Source can be connected in a number of ways including:

• Copy and paste all or part of one scenario into another. See Copying Network Elements.
• Scenario Data Sources
• Scenario Transfer Node

Each of these methods has advantages and disadvantages, discussed below.

Copying and pasting network elements

This is a simple method for joining scenarios into a larger one. Everything from one scenario can be copied and then pasted into another scenario within the same project (with the caveats listed in Copying Network Elements). Once you have pasted the network components, you can work with those components as you would for any scenario. A disadvantage of this method is that the copied scenario and the original are not linked in any way. 

Scenario data sources

Using a scenario data source is a simple mechanism for connecting models, outputs from one or more scenarios, the 'pitcher' donor scenarios, are used as inputs for another scenario - the catcher acceptor scenario. If you enable Reload on Run for a scenario data source, the results from the latest run of the pitcher scenario will be used as input for the catcher scenario. This means that any changes you make to the pitcher scenario can be passed on to the catcher, as long as you re-run the pitcher before running the catcher.  The First you run the donor scenario, then you select results to be used as data sources in the acceptor scenario, see Loading scenario data sources for more information. 

The main advantage of this method is that it can improve performance on large models; you can split the model in to parts (eg. upstream and downstream) and run them sequentially, using scenario data sources to input the results from an upstream model into the downstream model. . Furthermore, if you enable Reload on Run for a scenario data source, results from the latest run of the donor scenario will be used as input for the acceptor scenario, allowing you to pass results changes from the donor to the acceptor. 

The disadvantage of this method is that information can not cannot be passed from the receiving acceptor scenario to the upstream scenario. This means that 

 see Loading scenario data sources. 

Performance can be improved on large models by splitting the model in to parts and running them separately and then using scenario data sources. For example, a model can be split into an upstream and a downstream scenario. Then, the results from the upstream scenario can be a scenario data source in the downstream scenario. In this case, Reload on Run should generally be enabled, to ensure that the downstream scenario is always using the most recent results from the upstream scenariodonor scenario, so you cannot, for example, XXXXX.

Scenario transfer node

The Scenario transfer node (STN) handles the joining of two scenarios with linked:

• Constituents
• Orders, and
• Ownership.

 Because STNs operate in both connected and disconnected mode, you can 

 

Anchor
ScenarioTransferNode ScenarioTransferNode

Scenario Transfer Node 

The Scenario transfer node (STN) handles the joining of two scenarios and conceptually, comprises of two components (as shown in Figure 1). The node links two scenarios and runs them together. 

The STN operates in either a connected or disconnected mode:

• When processing a connected execution, the pitcher passes all components of the pitcher scenario to the catcher, hence linking the two scenarios together; and
• For a disconnected execution (ie. scenarios are run independent of each other), the pitcher acts like a minimum flow requirement node and the catcher models an inflow node.

Figure 1. Scenario Transfer node

Note the following when working with linked scenarios:

• Constituents are passed from one scenario to another;
• Orders are passed between linked scenarios;
• Off allocation does not operate over scenarios. In this mode, the STN operates like an off allocation boundary - similar to the transfer ownership node;
• Ownership is passed across boundaries.

Constituents

A model will operate even if the constituent processing methodology (lumped or marker) is different for each scenario. For example, consider the pitcher scenario is configured with lumped routing and the catcher scenario with marker routing. Constituents will be passed from the pitcher to the catcher even though the methodology is not the same.

Once constituents are defined in both the pitcher and catcher scenarios, you can map constituents between the two scenarios using the STN feature editor. Choose Connected > Constituent Mapping from the tree and click Add (as shown in Figure 2). 

Figure 2. STN, Constituent mapping

Ownership

Ownership can be set up in linked scenarios using Connected > Ownership in the feature editor (as shown in Figure 3). Configuration of ownership is similar to the Transfer ownership node (when set up as a boundary node). 

Figure 3. STN, Ownership