Enabling and disabling contact in subcases (SOL 402)

In SOL 402 analyses, you enable contact by adding the contact simulation object to a subcase, and you disable contact by omitting the contact simulation object from a subcase. Whether the corresponding contact condition ramps on, ramps off, or remains static in a subcase depends on the ending status of the subcase that precedes it. In general:

• Contact condition is ramped on in the first subcase where the contact is added (enabled).Thus, you must add the contact to the subcase that precedes the one where you require the contact condition to be fully enabled. To keep the contact condition fully enabled, add (enable) the contact to the subsequent subcases.

• Contact condition is ramped off in the first subcase where it is omitted (disabled).Thus, you must omit the contact from the subcase that precedes the one where you require the contact condition to be fully disabled. To keep the contact condition fully disabled, omit (disable) the contact from the subsequent subcases.

Note:

Special considerations apply to the first subcase in the solution and your setting for initial contact status. See Setting initial contact status below.

Enabling and disabling a contact

The following example shows how to enable a contact and then disable it. In this example, the solution has five subcases. Suppose you want contact to be fully enabled only in Subcases 3 and 4. To accomplish this:

1. Add the contact to the subcase that precedes the one where you require the contact to be fully enabled (Subcase 2 in this example).Caution: To ensure that the contact condition is ramped as expected in Subcase 2 in this example, you must understand the effect of the initial contact status as explained in Setting initial contact status below. By default, the initial contact status is set to active. In this example, you would need to set the initial contact status to inactive.

2. Add the contact to the subcases during which you want it to be fully enabled (Subcases 3 and 4 in this example).

3. Omit the contact from the subcase where you want the contact condition to be ramped down (Subcase 5 in this example).At the end of Subcase 5, the contact is fully disabled.Note: Even though contact is disabled in Subcase 5 (no contact is in the Simulation Objects node), the contact is ramping down and still influences the computation. The influence of the ramping of the disabled contact is easy to overlook when no contact is visible in the subcase.

Setting initial contact status

The Contact Pair Status when the Simulation Starts (ACTIVE) option in the Contact Parameters - Multi-Step Nonlinear Kinematics Pair modeling object sets the status of the first contact in the solution. Because contact in each subcase depends on its initial status from the previous subcase, you can think of this option as setting the status of an imaginary Subcase 0 (same as time=0.0) that precedes the actual Subcase 1. Subcase 1 starts with the contact status you set for this Subcase 0. How Subcase 1 uses the contact status from Subcase 0 depends on whether contact is enabled (contact is present) or disabled (contact is omitted) in Subcase 1.

This can appear to be counter intuitive because the Contact Pair Status when the Simulation Starts (ACTIVE) option affects Subcase 1 even if Subcase 1 does not contain contact. This occurs because the omission of a contact in a subcase is the same as disabling a contact, as explained above in Enabling and disabling a contact.

Note:

By default, the Contact Pair Status when the Simulation Starts (ACTIVE) check box is selected, which means that Subcase 1 considers the contact active even if it contains no contact.

The following examples show how the combination of the initial contact status (Contact Pair Status when the Simulation Starts (ACTIVE)) and the presence or omission of the contact simulation object in Subcase 1 determine the four different ways that contact condition can be implemented in Subcase 1:

• Contact condition fully active

• Contact condition ramping on

• Contact condition ramping off

• Contact condition fully inactive

Example 1 — Effect of initial contact status when contact is enabled in Subcase 1

This example illustrates the difference between setting the initial contact status to active (Contact Pair Status when the Simulation Starts (ACTIVE) ) and inactive (Contact Pair Status when the Simulation Starts (ACTIVE) ) when contact is enabled in Subcase 1.

Contact activation strategy	Initial contact status	Contact behavior
Contact is enabled in Subcases 1, 2, and 3, and disabled in Subcase 4.	Contact Pair Status when the Simulation Starts (ACTIVE) This is the equivalent of enabling contact in a Subcase 0 that precedes Subcase 1. Because each subcase starts with the ending contact status of the previous subcase, Subcase 1 will start with contact enabled.	Because the initial contact status (Subcase 0) is active, and contact is enabled in Subcase 1, the contact condition in Subcase 1 is applied in full immediately at the start of the solution. No ramping occurs. This is the same as adding the contact to the subcase (Subcase 0) that precedes the subcase (Subcase 1) where you require the contact to be fully enabled.Contact is enabled in Subcases 2 and 3, so the contact status remains active. Contact is disabled in Subcase 4, but the starting contact status (from Subcase 3) is active, so the contact condition is ramped down. Contact conditions always ramp down in the subcase in which the contact is disabled, so ramping down begins in Subcase 4 and completes at the end of Subcase 4.
Contact Pair Status when the Simulation Starts (ACTIVE) This is the equivalent of disabling contact in Subcase 0. Because each subcase starts with the ending contact status of the previous subcase, Subcase 1 will start with contact disabled.	Because the initial contact status (Subcase 0) is disabled, but contact is enabled in Subcase 1, the contact condition in Subcase 1 is ramped on.Contact is enabled in Subcases 2 and 3, so the contact status remains active. Contact is disabled in Subcase 4, but the starting contact status (from Subcase 3) is active, so the contact condition is ramped down. Contact conditions always ramp down in the subcase in which the contact is disabled, so ramping down begins in Subcase 4 and completes at the end of Subcase 4.

Example 2 — Effect of the initial contact status when contact is disabled in Subcase 1

This example illustrates the difference between setting the initial contact status to active (Contact Pair Status when the Simulation Starts (ACTIVE) ) and inactive (Contact Pair Status when the Simulation Starts (ACTIVE) ) when contact is disabled (omitted) in Subcase 1.

Contact activation strategy	Initial contact status	Contact behavior
Contact is disabled in Subcase 1, enabled in Subcases 2 and 3, and disabled in Subcase 4.	Contact Pair Status when the Simulation Starts (ACTIVE) This is the equivalent of enabling contact in a Subcase 0. Because contact status in each subcase starts with the ending status of the previous subcase, Subcase 1 will start with contact enabled.	Because the initial contact status (Subcase 0) is active, but contact is disabled in Subcase 1, the contact condition is ramped down.Contact is enabled in Subcase 2, and contact conditions are always ramped on when a contact is first enabled, so the contact condition is ramped until the end of the subcase.Contact is enabled in Subcase 3, and Subcase 3 begins with an enabled contact from the preceding Subcase 2, so the contract remains enabled.Contact is disabled in Subcase 4, and contact conditions are always ramped down in the subcase in which the contact is first disabled, so ramping down begins in Subcase 4 and completes at the end of Subcase 4.
Contact Pair Status when the Simulation Starts (ACTIVE) This is the equivalent of disabling contact in Subcase 0. Because contact status in each subcase starts with the ending status of the previous subcase, Subcase 1 will start with contact disabled.	Because the initial contact status (Subcase 0) is inactive, and contact is disabled in Subcase 1, the contact remains disabled.Contact is enabled in Subcase 2, and contact conditions are always ramped on when a contact is first enabled in a subcase, so the contact condition is ramped until the end of the subcase.Contact is enabled in Subcase 3, and Subcase 3 begins with an enabled contact from the preceding Subcase 2, so the contact remains enabled.Contact is disabled in Subcase 4, and contact conditions always ramp down in the subcase in which the contact is first disabled, so ramping down begins in Subcase 4 and completes at the end of Subcase 4.

Contact at the solution level

All the simulation objects that appear in the Simulation Objects container at the solution level and not in a Simulation Objects container at the subcase level are enabled for the entire computation.

Contact at the subcase level

When you create a new subcase, you must add the Simulation Objects container by right-clicking the subcase and choosing New Boundary Condition Container→Simulation Objects. The option to add the Simulation Objects container is available only for subcases that allow you to add simulation objects at the subcase level.

Managing contact simulation objects

Contact simulation objects are boundary conditions like loads and constraints. For information on creating them, adding them to solutions or subcases, and managing them in folders, see Managing boundary conditions.

Enabling and disabling contact in subcases (SOL 402), Simcenter 3D 2021.1 Series

© 2020 Siemens

window.mainLanguage="en_US"

window.delivId=""

window.projectId=""

MathJax.Hub.Config({ TeX: { extensions: ["autoload-all.js"] }, tex2jax: { displayMath: [ ] }, "SVG": { scale: 125 } });