Importing SubModels

In some cases, you may want to import an existing stand-alone model into another file as a SubModel. This is useful, for example, if you want to export a SubModel to test (and refine it) outside of the parent model, and then import it back into the parent model.

To import a stand-alone model into your current model as a SubModel, you must insert a SubModel from the Insert Element menu. When you insert a SubModel, you are presented with a dialog asking if you want to create a new (empty) SubModel, or create the SubModel by importing an existing standalone model. You should choose the latter. When you do so, you will be prompted for a filename and location. After selecting it, the specified file will be inserted into the parent model as a SubModel.

There are several rules that must be met in order for the model to be successfully inserted as a SubModel:

• The stand-alone model must have been saved using the same version of GoldSim that is trying to import it.

Note: If the model being imported contains Scenarios, the scenario information will be removed when it is imported and only the information pertaining to the Active Scenario will be imported.

When importing a model, all of the information on the Globals tab of the Simulation Settings dialog in the stand-alone model is imported into the input interface for the SubModel.

Note: If the model being imported was previously exported from a SubModel to a stand-alone model, the original exported Definitions for the input and output interface will be automatically recreated when the model is imported to recreate it as a SubModel. Any changes to existing input Definitions will be ignored (the Definitions that existed when the model was exported will be used). Any new input Definitions that were added after the model was exported, however, will be added to the interface.

If you import a GoldSim model as a SubModel, and that model has Resources defined, the Provide Resources checkbox will automatically be checked, and any Resource Types and Stores defined in the original model will become part of the SubModel. The Resources in the SubModel and those in the parent model are completely separate and independent. Elements in the SubModel cannot see or interact with Resources in the parent model.

Because the parent model and the imported model potentially could have conflicting definitions (for units, array label sets and version stamps), the following rules are followed during the import to ensure consistency.

When importing an existing model as a SubModel, all of its array label sets are imported into the parent model. Therefore, existing sets and imported sets must be merged. The following rules apply when importing array label sets:

• Any set that exists in the imported model but not in the parent model is automatically added to the parent model.

• If the imported model and the parent model have sets with identical names (set names are not case-sensitive) that are not otherwise identical (i.e., they must have the same number of items with the same index names), an error is displayed and the import of the model will fail.

When importing an existing model as a SubModel, all available user-defined units in the existing model are imported into the parent model. Therefore, existing units and imported units must be merged. The following rules apply when importing units:

• If the imported unit name is identical to an existing unit name, and the units have the same dimensions, but are assigned to different categories, then the unit is assigned to the category specified by the parent model.

• If the imported unit name is identical to an existing unit name, and the units have the same dimensions, but are assigned different conversion factors, then the conversion factor is assigned the value specified by the parent model.

• If the imported unit name is identical to an existing unit name, but the units have different dimensions, an error is displayed and the import of the model will fail.

When importing a model file that includes versioning information, GoldSim evaluates the version stamps and compares them against the version stamps in the existing model (if it uses versioning).

If all version stamps are identical (i.e., all properties must match: stamp number, name, description, user name), then the imported model elements keep their individual version logging information. Globally logged information from the imported model, however, is lost.

If the version stamps are not identical, or if the existing (parent) model does not use versioning, all version information is removed from the imported model and its elements.