MSC SuperModel uses the ability of MSC.Patran to merge databases. As assembly models (SuperModels) are more conveniently distributed among several component models (submodels),
a global analysis of the entire structure requires the ability to join component models. MSC SuperModel supports a batch mode of database merge through the Analysis Management and Job
Definition functionality.

Merging components to form an assembly structure for analysis lies at the heart of MSC SuperModel. Sometimes, numbering and naming schemes are desired to more easily identity the location and source of a modeling entity.

For example, in a multi-company partnership, the prime contractor may use finite element node and element ID’s 0 through 99,999 while subcontractor A uses 100,000 through 199,999, subcontractor B uses 200,000 through 299,999, etc. Each team member is typically responsible for a number of components. The numbering schemes may be further refined by component. For example, if subcontractor A is responsible for five components, the entity numbering scheme may be evenly divided among the five components (e.g., 100,000 - 119,999, 120,000 - 139,999, 140,000 - 159,999, 160,000 - 179,999, 180,000 - 199,999). Naming conventions may follow the rule where unique model attributes (e.g., special component loadings) have unique names while common model attributes (e.g., materials) have common names. The model merge capability in MSC.Patran supports these scenarios.

The interactive model merge functionality can be accessed from two locations under the File Manager menu: Utilities - FM Import and the UNIX Import option on the File Manager menu.

The following form is the FM-Utilities-FM Import form. Currently the only file type that can be imported using this form is a PATRAN database. Other file types (CAD geometry, PATRAN Neutral File, MSC.Nastran input file, etc.) must be accessed using the UNIX Import option.

The following form is the UNIX Import form accessed directly from the FM menu. This is the standard MSC.Patran import form.

From the File Manager UNIX Import form, set the Object selection to Model and Source selection to MSC.Patran DB. The Import form updates to reflect the database import options, as well as present the available MSC.Patran databases in each directory structure.

MSC.Patran always initializes a database to contain the group default_group. This group is commonly used to contain the entire model’s contents while additional groups divide the model based on functionality, user’s preference, etc. If default_group is to contain the whole model, then it should be designated as the Current Group on the Import form. When a submodel is imported, all the entities are stored in the Current Group; if this group does not exist, is automatically created.

During the import of a submodel, at least one new group is created, that contains the incoming model’s contents. Typically this group is designated SM_XXX where SM stands for submodel and XXX is a three-digit identifier representing the number of components currently imported into the database (e.g., the fifth component would result in the creation of group SM_005 that contained all of the component’s entities).

Several automated modeling functionalities are optionally available during model import, including naming and numbering conventions, merging of similar model information, filtering of entities access, geometric and finite element equivalencing. The incoming database can be previewed prior to import. Each of these functionalities is discussed in more detail in the following sections.

The MSC.Patran DB Import Options form is a multi-purpose spreadsheet that allows for the specification of entity types and selected groups to be imported, shows the minimum/maximum ID ranges of each numbered entity type in the current database, and provides options for defining offsets and prefixes for resolving conflicts between numbered entities and named entities, respectively.

Entity numbering control can serve two purposes:

The second purpose is discussed in detail.

Numbered entity ID’s (geometry, finite element data) may be assigned based on specified ranges. These ranges may vary between companies jointly working on a product and even within a particular company, possibly based on product component. While each individual component in an assembly may have ID’s that begin at one, they may have to be reset to an assigned range when merged into the assembly model. The MSC.Patran DB Import Options form supports three methods of ID offsets: Default, Automatic
and Input.

Fixed increments that reflect the number of submodels previously imported. For example, if components of an assembly are to have ID increments of 10,000 then the first component imported would start at 10,000, the second at 20,000, etc. Default offset schemes are specified at the top of the options form as shown below. It is important to note that both the Increment and Submodel numbers may be overridden; the final Default Offset is the product of the Increment and Submodel number.

The Default numbering scheme may be used for one or more of the numbered entity types. To apply the Default Offset to all numbered entities, select the ID Offset heading cell.

The Offset Options form appears. Select the Default Offset Option and choose the Apply button. All the numbered entity offsets uses the Default Offset numbering scheme.

If a Default numbering scheme is desired for selected entity types, select one or more databoxes and select the Default method.

Use the next highest entity number available as a starting point. Therefore, all entities appears sequentially numbered with no ID gaps to distinguish components. Automatic Offsets may be applied to all entity IDs or selected entity types, just as with the Default Offset previously described. To apply an Automatic numbering scheme, select the Automatic Offset Option and press the Apply button.

Allow the user to manually specify the ID offset value. One application of Input Offsets would be if components are originally numbered not starting with one but rather at their desired offset value as when assembled into the final configuration; in this case, an Input Offset of zero is required to indicate that the imported entity ID’s are to remain unchanged. As with Default and Automatic Offsets, an Input Offset may be applied to all entity IDs or selected entity types. To apply an Input numbering scheme, select the Input Offset Option, supply the Offset Value and press the Apply button.

Entity naming control can serve two purposes:

The later purpose is discussed in detail.

Element properties, materials, loads/boundary conditions, groups, fields and Load Cases are all named entities. Depending on modeling practices, it may be desirable to distinguish the source of named entities in an SuperModel (e.g., by contractor, project engineer, submodel, etc.). The MSC.Patran DB Import Options form supports two methods of distinguishing named entities by name prefixes: Default and Input.

Typically a combination of fixed leading text concatenated with the imported submodel number (i.e., SM_005_ for the fifth imported submodel). These prefixes is always be applied unless the optional merge duplicate toggle is enabled for one or more named entities (see discussion below). Default prefix schemes are specified at the top of the options form. It is important to note that both the Increment and Submodel numbers may be changed.

The Default naming scheme may be used for one or more of the named entity types. To apply the Default Prefix to all named entities, select the Name Prefix heading cell.

After selection of one or more cells under Name Prefix, the following prefix control form appears.

If a Default numbering scheme is desired for selected entity types, select one or more databoxes and select the Default method.

Allows the user to manually specify the Prefix. An application of the Input value is to enter a blank value because the named entity types already reflect their source, etc., in the respective submodels (i.e., their names are already unique at the submodel level). As with Default Prefixes, an Input Prefix may be applied to all or selected named entity types. To apply an Input naming scheme, select the Input Prefix Option, supply the Prefix and press the Apply button.

As previously discussed, numbered and named entities may be distinguished by a default convention that involves a submodel numbering scheme. The submodel number is a count of successful database imports. It is, however, extracted from the prefix used on the groups from previous successful imports. For example, if Group default_group was previously imported with prefix SM_003_, then the new group is named SM_003_default_group. That prefix is subsequently used to determine the submodel number for the next import, where the maximum is tracked for all groups. So, the SM_003_ prefix indicates the maximum submodel number is 3; therefore the submodel number for the next import is 4. As a result, if the user chooses to blank out the submodel portion of the prefix, or uses a non‑numeric convention, then the submodel number will always be one.

Submodels comprising a SuperModel typically have common modeling attributes, including materials, element properties, loads/boundary conditions, and Load Cases. It is highly desirable to provide a mechanism for merging these common model attributes during the assembly of a SuperModel. The reasons for merging include database storage efficiency and assimilation of loads/boundary conditions for subsequent analysis.

Groups, Element Properties, Materials, Fields, loads/Boundary Conditions and Load Cases may all be optionally merged during submodel import. The default operation for each of these data types is to merge common data. The following criteria must be satisfied for two submodel data attributes to be merged:

The MSC.Patran DB Import Options form contains a section for controlling the optional merge operation. The following shows that each named entity type has an ON/OFF toggle. By default, these toggles are ON.

If a merge toggle is OFF, or the merge attempt fails, then the specified entity prefix is inserted in front of the name, and a new database entity is created to hold the data.

The Real Number Equality Criteria is used to determine when two real properties (scalar or vector components) are close enough in value to be assumed equal. Near equality is determined by comparing digits of the two numbers in normalized exponential form, from left to right and discarding leading zeroes, up to the specified number of significant digits. Of course, if the two numbers do not share the same exponent, then they are not considered equal. For example, if Significant Digits is set to 3, then 0.234516E+08 and 0.234925E+08 are considered equal, whereas 0.233925E+08 and 0.234925E+08 are not.

Entities of different types (e.g., geometric surfaces, finite elements, groups) may be entirely or partially imported or excluded from import. The import column indicates which entities of a given type are to be imported from the import database. The options are All, None or List.

If the Import? cell or multiple cells from the Import column are selected, the values for those cells are toggled from All to None, or vice-versa.

If a single cell is selected, the user then has the additional ability to specify which numbered or named entities to import by using the Input toggle.

The Minimum ID and Maximum ID columns show the range of IDs for the corresponding entity type in the current database. These values may be used to decide what offset values are most appropriate for that entity type; this would typically be the case when the Input method of specifying entity numbers was being used versus the more automated Default numbering convention.

There is no similar information for named entities.

Submodel integration requires that, at minimum, finite element nodes on the boundary be stitched together with the other previously imported submodels. Automatic equivalencing of finite element nodes and geometry between submodels may be invoked during submodel import through the Equivalence Options form, accessible from the Import/PATRAN DB form.

Only entities that are common between the current model and the import submodel are considered for equivalencing. If duplicate entities in either model are found, but none of those duplicates belong to the opposing model, then no action is taken. Equivalencing does not occur between entities originally from the current database or import submodel.

The finite element nodes that are equivalenced during submodel import are highlighted on successful import completion. A text report detailing the equivalenced entities can be requested on the Equivalence Options form.

A special set of rules and options have been implemented for the case when two or more Loads/Boundary Conditions are to be merged and nodes from the current model and import submodel belonging to a merged LBC set are also to be equivalenced. See Figure 4‑1.

In Figure 4‑1, nodes 1 and 10, 2 and 11, 3 and 12 are to be equivalenced. Additionally, the LBC set F1 from the two models is to be merged. The discrete forces applied to the boundary nodes are intentionally shown as unique at each node. This example is referenced in subsequent discussions explaining the merge rules.

The only LBC data that is considered for combination in this particular example is when it is defined using Fields. Fields other than Discrete Finite Element must be identical in their definition, but not necessarily their name (i.e., they must have the same PCL function describing the field); as their contents must be identical, nodes along the boundary remains unchanged and therefore present a trivial condition. The more interesting condition is when a discrete finite element field exists along a boundary with differing values.

LBCs that contain only constant scalar or vector data, not defined with fields, are not combined when nodes are equivalenced. Rather, the application regions in all effected LBCs are updated to reflect the equivalenced node numbers. This design limitation is intentional because resolving constant valued LBCs when nodes are equivalenced along a boundary would require the creation of a new LBC to model the LBC along the submodels interface.

If LBCs satisfying the rules in the equivalence table previously discussed exist and they contain boundary nodes that are to be equivalenced and the LBC data is described using discrete finite element fields, then a set of LBC merge rules is followed. These merge rules are accessed from the Import/PATRAN DB Equivalence Options form.

Two options are available for both displacement boundary condition and load condition data defined using vectors in a discrete finite element field.

For loads and boundary condition data defined by scalar data in a discrete finite element field, three options are available:

A special case is accounted for when the option for vector data is add and for scalar data is either add or average. This is the case where the nodes to be equivalenced both exist in the same discrete finite element field. In this case, the add or average logic is ignored and the overwrite logic is always applied.

A special set of rules have been implemented to determine the analysis coordinate system at equivalenced submodel boundary nodes. The existence of LBCs at one or both nodes to be equivalenced affects the final analysis coordinate system.

The following terminology is used in the Coordinate System Merge Rules table: (a) Local -1 = Local coordinate system, (b) Local-2 = Local coordinate system other than Local-1, (c) Local = any local coordinate system.

Prior to submodel import, the MSC.Patran database contents may be previewed; currently, the information provided includes the number of each entity type, and for numbered entities their minimum and maximum IDs. This information may be accessed from the Import form, from the numbered entity ID Offset Options form, or from the named entity Prefix Options form.

The database name is retrieved from the Import form. If a valid name has not been provided, the user is prompted for a proper database name.