Overconstraint Checks

Examples of intersecting tie constraint definitions are shown in Figure 2.

Consistent overconstraints because of intersecting tie constraints.

In both cases there is at least one node that, if not properly treated, will be redundantly constrained. In the case on the left, the three edges belonging to the three surfaces overlap (shown here in an exploded view for clarity). Each of the three end nodes on either end occupy the same location. Therefore, one redundant tie constraint exists. In the case shown on the right, four adjacent meshes are “glued” together using four tie constraints. Only three constraints are needed to “glue” the center nodes together, but four are generated (one from each tie constraint). Therefore, one constraint is not needed and in both cases one constraint is removed.

An example of a tie constraint inside a rigid body constraint is shown in Figure 3(a). Two surfaces are connected by a tie constraint, and the two element sets are included in the same rigid body. Since the motion of all the nodes is constrained to the motion of the rigid body's reference node, the tie constraint is redundant. The tie constraint definition is removed from the model.

Consistent overconstraints because of combinations of tie and rigid body constraints.

An example of a tie constraint between two rigid bodies is shown in Figure 3(b). If the two surfaces are connected by a tie constraint at more than two or three points (in two- or three-dimensional analyses, respectively), the tie constraint definition is redundant. A connector type BEAM is placed between the two reference nodes, and the tie constraint is removed.

An example of connecting a deformable body to a rigid body with a surface-based tie constraint is shown in Figure 3(c). If the secondary surface in the tie constraint definition belongs to the rigid body, the tie and the rigid body constraints are redundant for the secondary nodes. If possible, Abaqus/Standard will switch the main and the secondary surfaces in the tie constraint definition. If switching the main and the secondary surfaces is not possible because of other modeling restrictions, an error message is issued and the analysis is stopped.

Figure 4(a) illustrates the case when two rigid bodies partially overlap and, thus, the union of the two bodies behaves as one rigid body. However, the motion of the nodes in this region is governed by the motion of the two rigid body reference nodes; hence, the model is overconstrained. In Figure 4(b) several rigid bodies are included in a larger rigid body definition. The nodes belonging to the included bodies will be overconstrained.

Rigid body including other rigid bodies.

In both cases the rigid body constraint will be enforced only once for the nodes that belong to several rigid bodies. To enforce the rigid behavior of the ensemble, connector elements of type BEAM are generated between the rigid body reference nodes to ensure a rigid connection between the intersecting rigid body definitions.

There are numerous cases of overconstraints when a surface-based tie constraint and a boundary condition are used together, as illustrated in Figure 5.

Overconstraints involving tie constraints and boundary conditions.

In the first case nodes A and B are constrained to move together by the tie constraint. The vertical symmetry boundary conditions will constrain the motion of both nodes in the horizontal direction, generating one redundant constraint. In the second case the two specified boundary conditions conflict, thus generating a conflicting constraint.

For every tie-dependent node with a boundary condition, Abaqus/Standard first determines which independent nodes are involved in the tie constraint (see Mesh Tie Constraints). If only one independent node is involved, Abaqus/Standard will transfer the boundary conditions from the dependent node to the independent node. If conflicting boundary conditions are detected at the independent node during the transferring process, the analysis is stopped and an error message is issued. If several independent nodes are involved, Abaqus/Standard checks if the specified boundary conditions at all the nodes involved in the constraint are identical. If no conflicts are identified, the boundary conditions at the independent node are redundant and, therefore, ignored. Otherwise, an error message is issued, and the analysis is stopped.

Combinations of rigid body constraints and boundary conditions can lead to overconstrained models when boundary conditions are specified at nodes other than the reference node (Figure 6). In Figure 6(a) boundary conditions are specified at several nodes belonging to the rigid body. In Figure 6(b) symmetry boundary conditions are specified on the flat surface of the rigid body, and the body is spun around an axis perpendicular to the symmetry plane at the reference node.

Overconstraints because of boundary conditions applied at rigid body nodes.

In case (a) if the specified boundary conditions are not consistent with the rigid constraint, the model will be inconsistently overconstrained. In case (b) if the reference node has the symmetry boundary conditions, there is no need to have symmetry boundary conditions at the nodes of the flat surface. Abaqus/Standard will attempt to remove all boundary conditions specified at the dependent nodes and redefine them at the reference node. To do so, the consistency of the boundary conditions specified at the dependent nodes is checked. If the boundary conditions are not identical, an error message is issued and the analysis is stopped (since otherwise the solution of a nonlinear system of equations would be required in the general case to assess whether the boundary conditions are consistent or not). Otherwise, Abaqus/Standard will try to merge the boundary conditions at the dependent nodes with those at the reference node by:

• checking the consistency of the overlapping boundary conditions;

• moving to the reference node any boundary conditions specified at the dependent nodes but not specified at the reference node; and

• applying additional zero rotational boundary conditions at the reference node to compensate for the removed displacement constraints from the dependent nodes.

To illustrate, refer to Figure 6(b): as the symmetry boundary conditions specified at the dependent nodes are consistent with each other, they are removed from the dependent nodes and applied to the reference node (boundary condition in the 2-direction). In addition, the symmetry constraints preclude rotations about the 1- and 3-directions; therefore, zero rotational boundary conditions are applied to the reference node about these axes.

In most cases detection and automatic resolution of redundant constraints involving connector elements cannot be done by simple inspection of the constraints involved. However, the examples shown in Figure 7 are simple enough to be resolved automatically. It is assumed that the connector elements are connected to nodes on the rigid body whose rotational degrees of freedom are dependent on the rotation of the reference node. In Figure 7(a) the connector elements are assumed to enforce some kinematic constraints. They are redundant since the rigid body definition constrains the motion of all nodes to the motion of the rigid body's reference node. Abaqus/Standard automatically removes the connector elements from the model.

Redundant constraints involving rigid bodies and connector elements.

When connector elements are placed between two rigid bodies (as in Figure 7(b)), the model might be redundantly constrained. As shown in Figure 7(b), if a connector element of type BEAM (or WELD) is placed between two rigid bodies, the connection is rigid and any additional connector elements between the two rigid bodies are redundant. Abaqus/Standard will automatically remove these redundant connector elements.

When the ensemble of connector elements placed between two rigid bodies enforces more than the necessary translational and rotational constraints between the two rigid bodies, but none of the connectors is of type BEAM (or WELD), only warning messages are issued to signal the overconstraint situation. In these cases none of the connector elements can be eliminated automatically since the connection between the two rigid bodies might become underconstrained. To illustrate this situation, assume that in Figure 7(b) the two connectors were of type SLOT and TRANSLATOR. Thus, four translational constraints (in three dimensions) are enforced between the two rigid bodies, rendering the system overconstrained since only three translational constraints are needed to fully constrain the relative translation between the two bodies. However, if the SLOT were eliminated from the model, the model would become underconstrained and different from the original one. Only a warning message is issued in this case.

When all or some of the nodes involved in a kinematic coupling constraint belong to the same rigid body, the coupling constraint becomes redundant. The situation is illustrated in Figure 8. Node 101 is the reference node for the coupling constraint involving nodes 1001–1005. At the same time nodes 1001–1003 are included in the rigid body definition with reference node 102.

Redundant constraints involving coupling constraints and rigid bodies.

If the coupling constraint was defined as kinematic, it will not be enforced at nodes 1001–1003 to avoid overconstraining the model. The removed overconstraint might be inconsistent such as when incompatible boundary conditions are prescribed at the two reference nodes. However, the constraint will be enforced at nodes 1004 and 1005 since these nodes do not belong to the rigid body.

If a distributing coupling constraint was used instead, the model would not be overconstrained. However, if node 101 was added to the rigid body definition and nodes 1004 and 1005 were not included in the coupling constraint, the model would be overconstrained. Indeed, all nodes involved in the coupling constraint would be already constrained by the rigid body definition, making the coupling constraint redundant. To avoid the overconstraint, Abaqus/Standard will not enforce the coupling constraint in this case.

When boundary conditions are specified at all nodes involved in a distributing coupling constraint, the model might become overconstrained. Abaqus/Standard will issue a warning message outlining the cause of the potential overconstraint.

Potential overconstraints that might arise when a rigid body is involved in a mesh-independent spot weld definition are discussed in Mesh-Independent Fasteners.

Redundant constraints are common in cases when secondary nodes used in surface-based tie constraints (Mesh Tie Constraints) are also secondary nodes in contact, as illustrated in Figure 9. In Figure 9(a) nodes 5 and 9 are connected with a tie constraint, and both are in contact with a main surface. Since the two nodes are tied together, one of the contact constraints is redundant. A similar situation is presented in Figure 9(b): two mismatched solid meshes are connected with a tie constraint, and contact is defined with a flat rigid surface. Node S is a dependent node in the tie constraint, so its motion is determined by that of nodes B and C. Therefore, any contact constraint applied at node S is redundant. Moreover, the contact constraints at nodes G and H are redundant, since the motion of these nodes is determined by nodes B and C, respectively.

Redundant constraints arising from contact interactions and tie constraints.

To eliminate these redundancies when all nodes involved in the tie constraint are in contact, Abaqus/Standard will automatically apply a tie-type constraint between the Lagrange multipliers associated with the contact constraint. The redundant contact constraint is eliminated. The contact pressure and the friction forces at the secondary node are recovered from the pressures and friction forces at the associated tie-independent nodes.

Contact interactions and prescribed boundary conditions might lead to redundant constraints if either normal contact with the default “hard contact” formulation (Contact Pressure-Overclosure Relationships) or frictional contact with the Lagrange multiplier formulation (see Frictional Behavior) is invoked. Abaqus/Standard attempts to resolve these types of redundant constraints for contact pairs involving rigid surfaces.

Checks Related to Normal Contact Interactions

In Figure 10 the fixed analytical rigid main surface is in contact with a secondary node that has a fixed boundary condition specified in the direction normal to the contact surface. If during a particular increment in the analysis the node is in contact, the contact constraint is redundant and will not be enforced during that increment. If the boundary condition at the secondary node is in conflict with the boundary conditions at the rigid surface's reference node, an error message is issued and the analysis is stopped.

Overconstraints involving normal contact interactions and boundary conditions.

The contact and boundary conditions related to overconstraints are removed automatically only if the main surface is defined as an analytical rigid surface. In all other cases, if an overconstraint occurs during the analysis, a zero pivot message is issued by the equation solver (see below) and the chains of constraints responsible for the overconstraint are clearly outlined.

Checks Related to Lagrange Friction

A common redundant constraint case is depicted in Figure 11. The symmetry boundary conditions combined with the Lagrange friction are redundant.

Lagrange friction and boundary conditions.

The secondary node is in contact and the tangent to the surface is in approximately the same direction as the specified boundary condition at the secondary node. To avoid redundancy, at this node Abaqus/Standard will switch from the Lagrange friction formulation to the default penalty formulation (Frictional Behavior) if the motion of the main nodes is prescribed in the tangent direction.

A node set containing all the nodes in the chains of constraints associated with a particular zero pivot is generated automatically.

There is no unique way to remove the overconstraints in this model. For example, if one JOIN and REVOLUTE (five constraints) combination is replaced with a SLOT connector element, which enforces only the two translation constraints in the plane of the mechanism, there are no redundancies. Alternatively, you could remove the REVOLUTE from one of the connector elements and also use a SLOT connection instead of a JOIN in one of the other connector elements.

Another alternative is to relax some of the constraints. In the example outlined here, an elastic body could replace one or more of the rigid bodies. You could also relax the Lagrange multiplier-based constraints (e.g., JOIN or REVOLUTE) by using CARTESIAN and CARDAN connection types with appropriate elastic stiffnesses (see Connector Behavior).

After analyzing the chains of constraints, you have to decide which constraints have to be removed to render the model properly constrained and also best fit the modeling goals. For this example the three constraints cannot be removed randomly. Removing any three combinations of the six boundary conditions, for example, would make the problem worse: the model is still overconstrained, and three rigid body modes have been added to the model. Moreover, you should remove the constraints that do not affect the kinematics of the model. For example, you cannot completely remove a JOIN connection from any of the connector elements since the model would be different from that originally intended.

The overconstraint checks performed during input file preprocessing and during the analysis can be bypassed. Bypassing these checks is not recommended, as it might allow a model with overconstraints to enter into the analysis code. Bypassing the overconstraint checks is not step dependent; i.e., the setting is defined as model data and affects the entire analysis.

Automatic model modifications in the model preprocessor can be prevented. In this case Abaqus/Standard will still perform overconstraint checks, but no automatic redundant constraint resolution will be performed; only appropriate error messages will be issued. Preventing constraint resolution is not step dependent; i.e., the setting is defined as model data and affects the entire analysis.

By default, the overconstraint checks are performed at every increment during the analysis. You can modify the frequency of these checks (in increments) for each step in the analysis. If the frequency is set equal to zero, no overconstraint checks are performed during that analysis step. The frequency specification is maintained in subsequent steps until the value is reset.

By default, the analysis continues even though an overconstraint is detected. This behavior can be changed on a step-dependent basis. The analysis can be stopped the first time an overconstraint is detected in a step, or it can be stopped only if a converged solution is obtained despite the fact that overconstraints exist. This setting is maintained in subsequent steps until it is reset.