Feature Modeling's Effect on Instance Data

If an DesignModeler application feature modifies an instanced body, then the body will no longer be considered an instance. Generally, a feature may be destructive of pre-existing body instance data (existing before the feature is generated).

If there is only a single remaining body instance following the removal of the modified body instance data, then this remaining body will no longer be considered an instance. Note that no observable modifications will be made in the DesignModeler application geometric data other than the body instance data being modified.

The Share Topology feature will determine how part instances are formed for the purpose of transferring geometry to Mechanical application. Some exceptions are now noted:

Parts with Share Topology method Automatic or Imprint will be retained as instances after the execution of the Share Topology feature only for databases created from version 15.0 onward.

A part which has at least one body with “Edge-Joints” Share Topology type will be de-instanced by the Share Topology feature.

For parts to be instances of each other, it is required that corresponding bodies have the same Shared Topology Method property.

If a Spot Weld or Point Load is present on any instanced body, then any associated part instance data will be ignored during geometry transfer to the Mechanical application.

It may be noted that an implicit Share Topology feature will be created, if one doesn’t yet exist, during transfer of geometry from DesignModeler application to the Mechanical application. The creation of part instances in the Mechanical application will be as previously described.

For a better understanding, consider the following examples of the DesignModeler application feature modeling and transfer of part instance data to the Mechanical application.

Example 18: Scenario 1

Example 19: Scenario 2

Example 20: Scenario 3

Example 21: Scenario 4

The following icons represent the bodies:

For clarity, the part node for singleton parts are shown in the examples below, even though the DesignModeler application feature tree does not show the part node for single-body parts.

When displaying body lists, the following shapes denote body states:

Circle: non-instanced imported body or natively created body

Box: a body involved in an instanced relationship

Diamond: a body involved in an instanced relationship that has since been modified

Example 18: Scenario 1

User creates a native model in the DesignModeler application of a simple multibody part:

Part 1:

User patterns to create bodies as singletons:

Part 1:

Part 2:

Part 3:

Part 4:

When transferring this data to the Mechanical application, Part 1 will be un-instanced, while Parts 2, 3, 4 will be instances.

In the DesignModeler application, you explode Part 1:

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

When transferring this data to the Mechanical application, Part 1 would remain un-instanced, while Parts 2, 3, 4, 5 will be instances. This is because there would be no conflict between DesignModeler application parts and body instance data.

Example 19: Scenario 2

User creates a native model in the DesignModeler application of a simple multibody part:

Part 1:

User patterns both bodies and to create three copies of each, such that , and are copies of . Bodies , and are copies of . The Parts/Bodies feature tree list looks like this initially:

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

Part 6:

Part 7:

The following table illustrates various part layouts in the DesignModeler application and results of geometry transfer to the Mechanical application.

Body grouping Ansys DesignModeler by user

Part instancing in Ansys Mechanical

Explanation

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

Part 6:

Part 7:

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

Part 6:

Part 7:

In the Mechanical application { }, { }, { }, { }, { } and { } will be instanced parts. The multibody part { } will not be an instanced part.

Part 1:

Part 2:

Part 4:

Part 5:

Part 1:

Part 2:

Part 4:

Part 5:

When Share Topology types of all four parts are the same in the DesignModeler application, then the model is transferred as four instanced parts to the Mechanical application.

Part 1:

{None}

Part 2:

{None}

Part 4:

{Imprint}

Part 5:

{Imprint}

Part 1:

Part 2:

Part 4:

Part 5:

In the Mechanical application Part 1 and Part 2 are instances of each other, as will be Part 4 and Part 5.

Part 1:

{Automatic}

Part 2:

{Automatic}

Part 4:

{None}

Part 5:

{Imprint}

Part 1:

Part 2:

Part 4:

Part 5:

In the Mechanical application Part 1 and Part 2 are instances of each other. Part 4 and Part 5 will be uninstanced.

Example 20: Scenario 3

User imports a CAD model into the DesignModeler application with two singleton part instances:

Part 1:

Part 2:

User patterns to create bodies as singletons:

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

When transferring this data to the Mechanical application, five instanced singleton parts are expected:

Now go back to the DesignModeler application and modify . Body list now looks like this:

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

When transferring this data to the Mechanical application, four instanced singleton parts , , , and an uninstanced singleton part are expected. This is due to body 2 having been modified and therefore removed from the DesignModeler application instance data.

Example 21: Scenario 4

User creates multibody part in the DesignModeler application.

Part 1:

User patterns to create bodies as singletons:

Part 1:

Part 2:

Part 3:

Part 4:

The DesignModeler application will consider bodies 2, 3, 4, 5 to be instances (without regard to DesignModeler application part data).

When transferring this data to the Mechanical application, Part 1 will be uninstanced, while Parts 2, 3, and 4 will be instances.

Next, user patterns Part1 ( ) to create bodies in the DesignModeler application:

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

Part 6:

The DesignModeler application will consider bodies , , , , , as one set of instanced bodies and bodies , , as another set.

When transferring this data to the Mechanical application, there would be no conflict between the DesignModeler application parts and body instance data. Thus, bodies , , would all be single-body part instances, and bodies ( , ), ( , ), ( , ) would all be multibody part instances.