Joining models

Join Models allows pairs of model objects to be combined into single merged objects.

This functionality allows different users to model separate parts of the system as different networks at the same time. The networks and the items associated with the networks can then be merged into a single model.

The model objects that can be merged are:

(If Run objects are selected for merging, items associated with the Run will automatically be selected for merging also.)

Merging Objects

To merge objects:

  1. Select the Join Models option from the Tools menu. The Join Models dialog will be displayed.
  2. On the Join Models dialog:
  3. Click the Join button to carry out the merge process.

Each pair of Primary and Secondary objects will be merged into a single object, which will be created in the location defined in the Join Models dialog.

Merging Rules

Details on merging rules are given below. General rules apply to all object types that can be merged. Exceptions to the general rules are detailed in the subsequent sections:

General Merging Rules

The following rules are applied to all items when carrying out the merging process:

Network Merging Rules

In general, when there is conflicting data between objects in the primary and secondary network, the primary object will take precedence. The following exceptions are applied when merging networks:

Merging a Fixed Head Node with a Transfer Node

A node present in both the primary and secondary network as a Fixed Head node in one network and a Transfer Node in the other, will be merged into a basic node with no control.

This is to allow for cases in which each network contains a simplified representation of the head / flow from the other network.

Merging Two Transfer Nodes

A node present in both the primary and secondary network as a Transfer Node, will be merged into a basic node with no control.

This is to allow for cases in which each network contains a simplified representation of the flow into / out of the other network.

Merging Nodes with Directly Allocated Demand

If a node in one (and only one) of the models has directly-allocated demand, this demand will be retained in the joined model.  If both models have directly-allocated demand for the node, then only the demand from the primary model will be retained and a warning will be displayed in the log.

This is to allow for cases in which connecting nodes may be on one side of a closed valve with demand allocated to the node in one model only.

Merging Nodes with Land Use Demands

If a node in one (and only one) of the models has Land Use demand allocated to it, this demand will be retained in the joined model.  If both models have Land Use demand allocated to the node, then only the demand from the primary model will be retained and a warning will be displayed in the log.

Control Data Merging Rules

In general, when there is conflicting data between objects in the primary and secondary Control, the primary object will take precedence. The following exceptions are applied when merging Controls:

UPC Scenario Merging Rules

In general, when there is conflicting data between regulator dependents in the primary and secondary UPC Scenario, the primary object will take precedence. The following exceptions are applied when merging UPC Scenarios:


Networks

Control Data

Demand Diagrams

Electricity Tariff Scenario

Demand Scaling

UPC Scenarios

Alternative Demand

Runs

Join Models dialog