Combining models with Submodel Import

Product(s): WaterGEMS, WaterCAD, HAMMER, StormCAD, SewerCAD, SewerGEMS, CivilStorm, PondPack
Version(s): CONNECT Edition, V8and V8 XM
Area:  Modeling

Table of Contents

Overview

This TechNote will explain how to import one model file ("submodel") into another model file ("target").  It is meant to provide clarification and explanation beyond what is given in the Help documentation. Note that this Technote was written for WaterCAD and WaterGEMS but the same concepts apply to HAMMER, StormCAD, SewerCAD, SewerGEMS, CIvilStorm and PondPack (V8 XM, V8i and CONNECT Edition)

Note: for the two most common issues / stumbling points with submodels, see:

Videos

Definitions

Target Model - The model that is accepting the submodel file.
Submodel - The model that is being imported.

Network Elements - The elements in your drawing pane that make up your model. These are junctions, pipes, valves, tanks, reservoirs, pumps , hydrants, etc.

 

Rules for Importing Submodels

1.    Existing elements in the target model will be matched with incoming elements from the submodel using their labels.
2.    Incoming submodel input data will override target model data for any element matched by its label.
3.    If a submodel element of the same label does not already exist in the target model, it will be created during the submodel import.

Element Types Governed by Submodel Rules

The rules for importing submodels govern the following element types:

Analysis Menu
Scenarios
Alternatives
Calculation Options

Components Menu
Controls
Pump Definitions
Unit Demands
Zones
Patterns
Minor Loss Coefficients
Pressure Dependent Demand Funtions
GPV Headloss Curves
ConstituentsValve Characteristics
Time Series Field Data

Tools Menu
User Data Extensions
Hyperlinks  


General Submodel import Process

When you have a need to combine multiple models together, the following guidelines are suggested:

1) Save a backup copy of each model

2) Decide which common scenarios and alternatives you want to keep in each model and clean them up (remove unwanted scenarios and alternatives).

3) Check that the scenario and alternative labels and structure match (for the ones you decided to keep for the single model)

4) Relabel elements as needed to ensure element labels are unique across the two models.

5) Clean up any artificial elements that connected the models. For example if there was a connection between the two models that you modeled as a constant reservoir or approximated pump+reservoir, you'll want to remove those artificial elements, and place real connectivity after the submodel import.

6) Import each model as a submodel into one "base" model. (open the base model and choose File > Import . Submodel) The one you pick for the "base" model likely doesn't matter but you may want to consider which symbology (and other things stored in the WTG) you want to keep. Only the elements and attributes will be imported from the submodel(s). If one model is smaller than the other, it may be easier to open the larger model and import the smaller one as a submodel.

7) Check the scenario and alternative manager to confirm that the data imported as expected.

8) Referring back to item 5: establish connectivity between the network(s) (models) as needed.

Example 1

In this example, the Submodel and Target Model have no elements in common (i.e., scenarios, alternatives, calculation options, and network elements do not match).

Town 'A' (The Target Model)

In the model illustration below, take notice of the labels for the elements outlined in red:

Alternatives e.g., "Year 2000 Active Topology" "Plus Two 18in Pipes," "Diameter times 2") 
Scenarios (e.g., "Year 2000 Conditions," "Plus Two 18in Pipes")
Calculation Options (e.g., "Year 2000 Conditions") 
Network Elements (e.g., Pipes P-90 and P-60, Junctions J-50 and J-40, Pumps, Reservoirs, Tanks, etc.)
 

  

 

Town 'B' (The Submodel)

In the model illustration below, take notice of the labels for the items outlined in red:

Alternatives (e.g., "Model_B_Active Topology") 
Scenarios (e.g., "Model_B_Average_Day") 
Calculation Options (e.g., "Model_B") 
Network Elements (e.g., Pipes B_Pipe-9 and B_Pipe-11, Junctions B_Junc-7 and B_Junc-6, Pumps, Reservoirs, Tanks, etc.) 

 

Result of Importing Submodel into Target Model

In the illustration below, the target model network elements are visible on the left, and the imported submodel network elements are outlined in red on the right. Since the target model elements have no label names in common with the submodel elements, all of the submodel elements will be created the target model, according to rule 3 above. None of the data in the target model will be overwritten in this case, since there were no matching labels.

Observe how the scenarios, alternatives, calculation options, and element labels for all the submodel items have been brought into the target model (see red outlined areas). For example, for the Active Topology alternatives, all of the submodel's (Town 'B') network elements have come in as inactive for the original "Year 2000 Active Topology." The reason is because the newly imported elements did not previously exist in that alternative, so the default attributes are used. In the case of active topology, the default is inactive. So, the newly imported elements are inactive in the "Year 2000 Active Topology" alternative. In the case of the physical alternative, if the submodel's physical alternatives don't match the target model's, the default physical attributes will be used for the newly imported elements, for the physical alternatives that already existed in the target model. So in this example, since the physical alternative in the submodel ("Model_B_Physical") doesn't exist in the target model, it was brought in as a new alternative. So, the pipes from the submodel in the scenarios that use the "Year 2000 Physical" will have 6" diameters and junctions will have zero elevations and so forth. In order to see the original attributes of the submodel elements, the scenario would need to use the "Model_B_Physical" physical alternative.

  


Example 2

 In this example, the submodel and target model have some elements in common (i.e., scenarios, calculation options, and network elements J-100, J-210, and P-250). 

Town 'A' (The Target Model)

 In the model illustration below, take notice of the labels for the items outlined in red:

Alternatives (e.g., "Year 2000 Active Topology" "Plus Two 18in Pipes," "Diameter times 2")
Scenarios (e.g., "Year 2000 Conditions," "Plus Two 18in Pipes")
Calculation Options (e.g., "Year 2000 Conditions") 
Network Elements (eg., Pipe "P-250" and Junctions "J-100" , "J-210")

 

 

 

Town 'B' (The Submodel)

  In the model illustration below, take notice of the labels for the items outlined in red:

Alternatives (e.g., "Model_B_Active_Topology")
Scenarios (e.g., "Year 2000 Conditions")
Calculation Options (e.g., "Year 2000 Conditions")
Network Elements  (eg., Pipe "P-250" and Junctions "J-100" , "J-210")

 

 

Result of Importing Submodel into Target Model

 In this model below we have connected the submodel (right) network to the target model network (left) at junctions J-100, J-210, and pipe P-250 (center). This connection occurs because both models shared some of the same junction and pipe labels as import rule 2 states. The submodel data is therefore going to overwrite the existing target model data in any items governed by the rules that are common to both models (illustrated below).  You can see that for both the submodel and target model there is also a common scenario name. If any of the properties for this scenario were different the submodel properties for this scenario would overwrite the properties for the target model. Above we see the target model network has all become inactive except for the junctions and the pipe that are shared by both models. This happens because the submodel data is overwriting the scenario data for the 'Year 2000 Conditions' scenario (import rule 2).   

 

 

In the illustration below, Town 'A' Demands and Pipe Diameter before the import are outlined in red

Junction Demands Pipe P-250 Diameter
J-100 = 19.60 gpm 6 inches
J-210 = 72.60 gpm

 

In the illustration below, Town 'B' demands and pipe diameter before the import are outlined in red

Junction Demands Pipe P-250 Diameter
J-100 = 72.0 gpm 8 inches
J-210 = 40.0 gpm

  

 

In the illustration below, pipe size and junction demands after the import are outlined in red

Junction Demands Pipe P-250 Diameter
J-100 = 72.0 gpm 8 inches
J-210 = 40.0 gpm

 

  

**If there is a case where the target model and the submodel share elements in common, as in the example above, but the X and Y coordinates differ they will be updated with the X and Y coordinates from the submodel.   


 

Example 3

 In this example, the submodel and target model share all of the same network elements but, none of the same scenarios, calculation options, or alternatives. 

Town 'A' (The Target Model) 

In the model illustration below, take notice of the labels for the items outlined in red:

Scenarios Calculations Options Alternatives
Average Day Demand Average Day Conditions Average Day <Alternative Type>
Fire Flow Fire Flow Fire Flow
Constituent Analysis Constituent Constituent Alternative - 1

 

 

Town 'A'_2 (Submodel) 

In the model illustration below, take notice of the labels for the items outlined in red:

Scenarios Calculation Options Alternatives
Peak Conditions Peak Condtiions Peak <Alternative Type>
Peak Times 2 Peak Times 2

 

 

 

Result of Importing Submodel into Target Model

In the model below we can see the import of the submodel results in all the network elements remaining the same because all these elements had the same labels. Hypothetically, if any of the properties of the network elements were different in the submodel from the target model the properties of the result would contain the values that were contained in the submodel (import rule 2). The significant change that happens in this model, much like in the first example, is that the scenarios, alternatives, and calculation options from the submodel all get added to the target model without overwriting anything.  

In the model illustration below, take notice of the labels for the items outlined in red:

Scenarios Calculation Options Alternatives
 Average Day Demand  Average Day Conditions Average Day <Alternative Type>
Fire Flow Fire Flow Fire Flow
Constituent Analysis Constituent Constituent Alternaitve - 1
Peak Conditions Peak Conditions Peak <Alternative Type>
Peak Times 2 Peak Times 2

 

Steps for completing a Submodel Export/Import 

1) Open the model that you want to export the submodel part from.

2) Select the part (or entire) model that you want to export. This can be done in many ways. Three common ways are by using your mouse to draw a box around certain areas, using your mouse to left click and select one element or multiple elements while holding down the shift key, or by holding down the CTRL key + A , which will select all the elements on screen. The default color for selected elements is red.

3) With the elements selected in the display panel go to File > Export > Submodel. Name and save your model to a location that you will remember.

4) Now open your target model and after it load go to File > Import > Submodel. 

Note: if you would like to import the entire model and not a subsection of the model, only step 4 is required. Meaning, in the target model, simply go to File > Import > Submodel, then select the .wtg.mdb file associated with the submodel you would like to import.

 

NOTE :

When importing submodels if both the submodels have UDX i.e. user data extensions defined for the same elements e.g. outfall has UDX defined in both submodels that you are importing, then an error is seen like:

Or

"Column 'AlternativeTypeID, Name' is constrained to be unique.  Value '100, Outfall_Field_13292' is already present."
The workaround is to remove the UDX from submodels, copy and paste that data in excel format and use Modelbuilder to import that UDX data. Once UDX data is removed from common elements you should be able to combine the submodels. We have filed a defect for this as of 10.03.XX.XX version, reference number is 306679 and we are working on it to get it resolved in future release of the products.
Additionally, when exporting a model containing "text" based UDX fields, the UDX fields are exported, but they don't contain any data i.e. they are blank. Formula based UDX fields also appear blank but are populated when the submodel is run. A defect for this (#475538) has been filed for this and we are working on it to get it resolved in future release of the products. As a workaround, copy the data from the flex-tables of elements containing the "text" UDX fields to a spreadsheet application (like Excel) and then use Modelbuilder to update the data in the exported submodel.

Troubleshooting

  • If you know you imported the model but don't see anything or are missing part of the model on in your display area.

              Answer:   Go to Tools > Options and see if the option on the Global tab for "Display Inactive Topology" is checked. Also notice the color the inactive topology is set to.

  • If all or part of the model you imported is gray

              Answer:    Your model has likely imported correctly but, all or part of it is currently inactive. If you want it to appear as an "active" status element the active scenario you have to use the active topology  tool (Tools > Active Topology Selection)  or go into the active topology alternative and change the status of the inactive elements. The reason this happens is because the active topology alternative in the submodel did not match the target model. So, the default status of inactive is used. If you do not want to manually change this in the resultant model, you will need to first go back to the target model and change the labels and structure of the active topology alternatives, so that they match between the models.

  • The attributes/data from the submodel were lost

      Answer:   If the properties of the submodel elements appear to use the default values (such as 6" for all diameters, zero elevation, etc), most likely the physical alternative(s) in your submodel did not match the physical alternatives in the target model. For example if a scenario and physical alternative exist in the base model but not in the submodel, any new elements imported from the submodel will use default values for physical properties in that scenario in the base model. You will either need to correct this manually, or go back to the target model and change the labels and structure of the alternatives so they match exactly to the target's 

  • What if models have same labels?

      Answer:   If models have duplicate labels such as "P-1" existing in Project A and P-1 in Project B as well, then the tool from the link below can be used to prefix the Labels before importing. Once the import process is done, the prefixed label can be removed too.
http://communities.bentley.com/other/old_site_member_blogs/peer_blogs/b/akshayas_blog/archive/2013/07/11/update-labels-of-a-hydraulic-model-using-waterobjects-net.aspx 

OR

You can use the relabel function in the flextables to relabel some elements. The wiki for how to do that can be found here;

How do I append a prefix to element labels based on a selection set of elements?

  • What if I want to combine Flushing areas or studies?

Answer: As of 10.01.00.72, Flushing Areas cannot be merged together with submodel import. All events will be import into all areas. You could manually clean this up after the submodel import, or wait for a future release which may have better handling for this situation (reference # 797290)

  • I do not want to over-write the controls of my main model when I bring in another model having controls with same ID's. How to accomplish this?

Answer: If you don’t not want your controls to be overridden, here is a suggested workflow;
1. In the model you wish to import, go to Components > Controls.
2. Select the controls and export them. In this you have two options
a. Either select all controls and export them together, in which case a single file will be generated to save. Drawback of this is that when you re-import these, all the controls will be imported.
b. Select each control and export individually. Benefit of this is that each control is stored separately. Hence you can choose which controls you require during import.
3. Save them to a separate location.
4. Delete all the controls in the model (you wish to import)
5. Now import the prepared sub-model into your main model.
6. In Components > Controls (you will see only the existing controls of your main model, as controls for the model you imported are deleted).

This way your original controls won’t be overridden by controls having the same ID’s. Additionally, you can import your controls (which were exported in Step 2) again if you wish to use them.

  • Model hang when trying to import a submodel into large, main model.

                 Answer: The problem may be related to the model's .DWH file. Try first deleting the DWH file. This file stores information on how the network appears in the drawing pane. This file is recreated when the model is re-opened. After deleting the .dwh file you should be able to import submodel into large main model. The problem may be related to the model's .DWH file. Try first deleting the DWH file. This file stores information on how the network appears in the drawing pane. This file is recreated when the model is re-opened. After deleting the .dwh file you should be able to import submodel into large main model.

NOTE : There is a bug in exporting submodels when customer meter elements are attached to pipes, the associated elements are not exported, this is reported in 10.03.05.05 version. For this patch has been developed, you can contact Technical Support  to avail the patch or patch will be incorporated in next release - 10.04.XX.XX version of WaterGEMS / WaterCAD. 

See Also

Pipes connecting to the wrong element after submodel import

Elements turning inactive and reverting to default properties after submodel import

Recommended
Related