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 donor scenarios, are used as inputs for another scenario - the acceptor scenario. 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. 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 cannot be passed from the acceptor scenario to the donor scenario, so you cannot, for example, link ordering systems.
Scenario transfer node
The Scenario Transfer Node (STN) is a more complicated method for connecting models together, but it differs it handles the joining of scenarios with linked:
Constituents
Orders, and
Ownership.
STNs can operate in both connected and disconnected modes. This allows you to develop different parts of a large model independently of each other as separate scenarios running in disconnected mode, and then you can run them together in connected mode. The disadvantage of this method is that when running in connected mode all scenarios that are connected to each other will be run, which may result in long run times. See Scenario Transfer Node for more information.
Scenario Transfer Node
The Scenario transfer node (STN) handles the joining of two scenarios and conceptually comprises of two components, the upstream and downstream STN (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 in connected mode, the upstream STN passes all components of the upstream scenario to the downstream STN, hence linking the two scenarios together; and
In disconnected mode (ie. scenarios are run independent of each other), the downstream STN acts like a minimum flow requirement node and the upstream STN models an inflow node.
Figure 1. Scenario Transfer node
Note the following when working with linked scenarios:
Constituents, orders and ownership are passed between the two scenarios;
Off allocation does not operate over scenarios. In connected mode, the STN operates like an off allocation boundary - similar to the transfer ownership node.
Configuring an STN
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).