김경종
33 KiB
text_image
tie constraint between faces ABCD-IJKL EFGH-KLNM ABRS-EHPO S O A L D R B K H G M F N (a) nodes B, H, K are at the same location nodes A, E, L are at the same location
text_image
M D tie constraint between faces AM–CD AB–HJ CE–FG HI–FN B A C E J H F G I N (b)
Figure 35.6.1–2 Consistent overconstraints due to intersecting tie constraints.
text_image
rigid body includes all elements tie constraint along this line element set 2 element set 1 tie constraint rigid body 1 rigid body 2 internally generated connector element reference node 1 reference node 2 (a) (b)
text_image
tie constraint deformable rigid (c)
Figure 35.6.1–3 Consistent overconstraints due to combinations of tie and rigid body constraints.
Tie constraint between two rigid bodies
An example of a tie constraint between two rigid bodies is shown in Figure 35.6.1–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.
Tie constraint between a deformable and a rigid body
An example of connecting a deformable body to a rigid body with a surface-based tie constraint is shown in Figure 35.6.1–3(c). If the slave surface in the tie constraint definition belongs to the rigid body, the tie and the rigid body constraints are redundant for the slave nodes. If possible, Abaqus/Standard will switch the master and the slave surface in the tie constraint definition. If switching the master and the slave surfaces is not possible due to other modeling restrictions, an error message is issued and the analysis is stopped.
Intersecting rigid bodies
Figure 35.6.1–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 35.6.1–4(b) several rigid bodies are included in a larger rigid body definition. The nodes belonging to the included bodies will be overconstrained.
flowchart
graph TD
A["reference node 1"] --> B["reference node 2"]
B --> C["internally generated connector element (type BEAM)"]
C --> D["intermally generated connector element (type BEAM)"]
D --> E["intermally generated connector element (type BEAM)"]
E --> F["intermally generated connector element (type BEAM)"]
F --> G["intermally generated connector element (type BEAM)"]
G --> H["intermally generated connector element (type BEAM)"]
H --> I["intermally generated connector element (type BEAM)"]
I --> J["intermally generated connector element (type BEAM)"]
J --> K["intermally generated connector element (type BEAM)"]
K --> L["intermally generated connector element (type BEAM)"]
L --> M["intermally generated connector element (type BEAM)"]
M --> N["intermally generated connector element (type BEAM)"]
N --> O["intermally generated connector element (type BEAM)"]
O --> P["intermally generated connector element (type BEAM)"]
P --> Q["intermally generated connector element (type BEAM)"]
Q --> R["intermally generated connector element (type BEAM)"]
R --> S["intermally generated connector element (type BEAM)"]
S --> T["intermally generated connector element (type BEAM)"]
T --> U["intermally generated connector element (type BEAM)"]
U --> V["intermally generated connector element (type BEAM)"]
V --> W["intermally generated connector element (type BEAM)"]
W --> X["intermally generated connector element (type BEAM)"]
X --> Y["intermally generated connector element (type BEAM)"]
Y --> Z["intermally generated connector element (type BEAM)"]
Z --> AA["intermally generated connector element (type BEAM)"]
AA --> AB["intermally generated connector element (type BEAM)"]
AB --> AC["intermally generated connector element (type BEAM)"]
AC --> AD["intermally generated connector element (type BEAM)"]
AD --> AE["intermally generated connector element (type BEAM)"]
AE --> AF["intermally generated connector element (type BEAM)"]
AF --> AG["intermally generated connector element (type BEAM)"]
AG --> AH["intermally generated connector element (type BEAM)"]
AH --> AI["intermally generated connector element (type BEAM)"]
AI --> AJ["intermally generated connector element (type BEAM)"]
AJ --> AK["intermally generated connector element (type BEAM)"]
AK --> AL["intermally generated connector element (type BEAM)"]
AL --> AM["intermally generated connector element (type BEAM)"]
AM --> AN["intermally generated connector element (type BEAM)"]
AN --> AO["intermally generated connector element (type BEAM)"]
AO --> AP["intermally generated connector element (type BEAM)"]
AP --> AQ["intermally generated connector element (type BEAM)"]
AQ --> AR["intermally generated connector element (type BEAM)"]
AR --> AS["intermally generated connector element (type BEAM)"]
AS --> AT["intermally generated connector element (type BEAM)"]
AT --> AU["intermally generated connector element (type BEAM)"]
AU --> AV["intermally generated connector element (type BEAM)"]
AV --> AW["intermally generated connector element (type BEAM)"]
AW --> AX["intermally generated connector element (type BEAM)"]
AX --> AY["intermally generated connector element (type BEAM)"]
AY --> AZ["intermally generated connector element (type BEAM)"]
AZ --> BA["intermally generated connector element (type BEAM)"]
BA --> BB["intermally generated connector element (type BEAM)"]
BB --> BC["intermally generated connector element (type BEAM)"]
BC --> BD["intermally generated connector element (type BEAM)"]
BD --> BE["intermally generated connector element (type BEAM)"]
BE --> BF["intermally generated connector element (type BEAM)"]
BF --> BG["intermally generated connector element (type BEAM)"]
BG --> BH["intermally generated connector element (type BEAM)"]
BH --> BI["intermally generated connector element (type BEAM)"]
BI --> BJ["intermally generated connector element (type BEAM)"]
BJ --> BK["intermally generated connector element (type BEAM)"]
BK --> BL["intermally generated connector element (type BEAM)"]
BL --> BM["intermally generated connector element (type BEAM)"]
BM --> BN["intermally generated connector element (type BEAM)"]
BN --> BO["intermally generated connector element (type BEAM)"]
BO --> BP["intermally generated connector element (type BEAM)"]
BP --> BQ["intermally generated connector element (type BEAM)"]
BQ --> BR["intermally generated connector element (type BEAM)"]
BR --> BS["intermally generated connector element (type BEAM)"]
BS --> BT["intermally generated connector element (type BEAM)"]
BT --> BU["intermally generated connector element (type BEAM)"]
BU --> BV["intermally generated connector element (type BEAM)"]
BV --> BW["intermally generated connector element (type BEAM)"]
BW --> BX["intermally generated connector element (type BEAM)"]
BX --> BY["intermally generated connector element (type BEAM)"]
BY --> BZ["intermally generated connector element (type BEAM)"]
BZ --> CA["intermally generated connector element (type BEAM)"]
CA --> CB["intermally generated connector element (type BEAM)"]
CB --> CC["intermally generated connector element (type BEAM)"]
CC --> CD["intermally generated connector element (type BEAM)"]
CD --> CE["intermally generated connector element (type BEAM)"]
CE --> CF["intermally generated connector element (type BEAM)"]
CF --> CG["intermally generated connector element (type BEAM)"]
CG --> CH["intermally generated connector element (type BEAM)"]
CH --> CI["intermally generated connector element (type BEAM)"]
CI --> CJ["intermally generated connector element (type BEAM)"]
CJ --> CK["intermally generated connector element (type BEAM)"]
CK --> CR["intermally generated connector element (type BEAM)"]
CR --> CS["intermally generated connector element (type BEAM)"]
CS --> CT["intermally generated connector element (type BEAM)"]
CT --> CU["intermally generated connector element (type BEAM)"]
CU --> CV["intermally generated connector element (type BEAM)"]
CV --> CW["intermally generated connector element (type BEAM)"]
CW --> CX["intermally generated connector element (type BEAM)"]
CX --> CY["intermally generated connector element (type BEAM)"]
CY --> CZ["intermally generated connector element (type BEAM)"]
CZ --> DA["intermally generated connector element (type BEAM)"]
DA --> DB["intermally generated connector element (type BEAM)"]
DB --> DC["intermally generated connector element (type BEAM)"]
DC --> DD["intermally generated connector element (type BEAM)"]
DD --> DE["intermally generated connector element (type BEAM)"]
DE --> DF["intermally generated connector element (type BEAM)"]
DF --> DG["intermally generated connector element (type BEAM)"]
DG --> DH["intermally generated connector element (type BEAM)"]
DH --> DI["intermally generated connector element (type BEAM)"]
DI --> DJ["intermally generated connector element (type BEAM)"]
DJ --> DK["intermally generated connector element (type BEAM)"]
DK --> DL["intermally generated connector element (type BEAM)"]
DL --> DJ
DJ --> DK
DK --> DL
style A fill:#f9f,stroke:#333
style BC fill:#f9f,stroke:#333
style BD fill:#f9f,stroke:#333
style BE fill:#f9f,stroke:#333
style CC fill:#f9f,stroke:#333
style DC fill:#f9f,stroke:#333
style BE fill:#f9f,stroke:#333
style BF fill:#f9f,stroke:#333
style BG fill:#f9f,stroke:#333
style BH fill:#f9f,stroke:#333
style BI fill:#f9f,stroke:#333
style BJ fill:#f9f,stroke:#333
style BK fill:#f9f,stroke:#333
style BL fill:#f9f,stroke:#333
style BM fill:#f9f,stroke:#333
style BN fill:#f9f,stroke:#333
style BO fill:#f9f,stroke:#333
style BP fill:#f9f,stroke:#333
style BQ fill:#f9f,stroke:#333
style CA fill:#f9f,stroke:#333
style CB fill:#f9f,stroke:#333
style CC fill:#f9f,stroke:#333
style DC fill:#f9f,stroke:#333
style BE fill:#f9f,stroke:#333
style BF fill:#f9f,stroke:#333
style BG fill:#f9f,stroke:#333
style BH fill:#f9f,stroke:#383
style BI fill:#f9f,stroke:#383
style BJ fill:#f9f,stroke:#383
style BK fill:#f9f,stroke:#383
style BL fill:#f9f,stroke:#383
style BM fill:#f9f,stroke:#383
style BN fill:#f9f,stroke:#383
style CA fill:#f9f,stroke:#383
style DB fill:#f9f,stroke:#383
style BE fill:#f9f,stroke:#383
style BF fill:#f9f,stroke:#383
style BG fill:#f9f,stroke:#383
style BH fill:#f9f,stroke:#383
style BI fill:#f9f,stroke:#383
style BJ fill:#f9f,stroke:#383
style BK fill:#f9f,stroke:#383
style BL fill:#f9f,stroke:#383
style CA fill:#f9f,stroke:#383
style DB fill:#f9f,stroke:#383
style BE fill:#f9f,stroke:#383
style BF fill:#f9f,stroke:#383
style BG fill:#f9f,stroke:#383
style BH fill:#f9f,stroke:#303
style BI fill:#f9f,stroke:#303
style BJ fill:#f9f,stroke:#303
style BK fill:#f9f,stroke:#303
style BL fill:#f9f,stroke:#303
style CA fill:#f9f,stroke:#303
style DB fill:#f9f,stroke:#303
style BE fill:#f9f,stroke:#303
style BF fill:#f9f,stroke:#303
style BG fill:#f9f,stroke:#303
style BH fill:#f9f,stroke:#303
style BI fill:#f9f,stroke:#303
style BJ fill:#f9f,stroke:#303
style BK fill:#f9f,stroke:#303
style BL fill:#f9f,stroke:#303
style CA fill:#f9f,stroke:#303
style DB fill:#f9i,stroke:#303
style BE fill:#f9i,stroke:#303
style BF fill:#f9i,stroke:#303
style BG fill:#f9i,stroke:#303
style BH fill:#f9i,stroke:#303
style BI fill:#f9i,stroke:#303
style BJ fill:#f9i,stroke:#303
style BK fill:#f9i,stroke:#303
style BL fill:#f9i,stroke:#303
style CA fill:#f9i,stroke:#303
style DB fill:#f9i,stroke:#303
style BE fill:#f9i,stroke:#303
style BF fill:#f9i,stroke:#303
style BG fill:#f9i,stroke:#303
style BH fill:#f9i,stroke:#303
style BI fill:#f9i,stroke:#303
style BL fill:#f9i,stroke:#303
style CA fill:#f9i,stroke:#303
style BJ fill:#f9i,stroke:#303
style BK fill:#f9i,stroke:#303
style BL fill:#f9i,stroke:#303
style CA fill:#f9i,stroke:#303
style BJ fill:#f9i,stroke:#303
style BK fill:#f9i,stroke:#303
style BL fill:#f9i,stroke:#303
style CA fill:#f9i,stroke:#383
style BJ fill:#f9i,stroke:#383
style BK fill:#f9i,stroke:#383
style BL fill:#f9i,stroke:#383
style CA fill:#f9i,stroke:#383
style BJ fill:#f9i,stroke:#383
style BK fill:#f9i,stroke:#383
style BL fill:#f9i,stroke:#383
style CA fill:#f9i,stroke:#383
style BJ fill:#f9i,stroke:#383
style BK fill:#f9f,stroke:#383
style BL fill:#f9f,stroke:#383
style CA fill:#f9f,stroke:#383
style BJ fill:#f9f,stroke:#383
style BK fill:#f9f,stroke:#383
style BL fill:#f9f,stroke:#383
style CA fill:#f9f,stroke:#383
style BJ fill:#f9f,stroke:#383
style BK fill:#f9f,stroke:#383
style BL fill:#f9f,stroke:#383
style C fill:#f9f,stroke:#383
style D fill:#f9f,stroke:#383
style E fill:#f9f,stroke:#383
style F fill:#f9f,stroke:#383
style G fill:#f9f,stroke:#383
style H fill:#f9f,stroke:#383
style I fill:#f9f,stroke:#383
style J fill:#f9f,stroke:#383
style K fill:#f9f,stroke:#383
style L fill:#f9f,stroke:#383
style M fill:#f9f,stroke:#383
style N fill:#f9f,stroke:#383
style O fill:#f9f,stroke:#383
style P fill:#f9f,stroke:#383
style Q fill:#f9f,stroke:#383
style R fill:#f9f,stroke:#383
style S fill:#f9f,stroke:#383
style T fill:#f9f,stroke:#383
style U fill:#f9f,stroke:#383
style V fill:#f9f,stroke:#383
style W fill:#f9f,stroke:#383
style X fill:#f9f,stroke:#383
style Y fill:#f9f,stroke:#383
style Z fill:#f9f,stroke:#383
Figure 35.6.1–4 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.
Tie constraints and boundary conditions
There are numerous cases of overconstraints when a surface-based tie constraint and a boundary condition are used together, as illustrated in Figure 35.6.1–5.
text_image
M G tie constraint between faces BJIE and AFHK A K J B F H C E I D symmetry boundary conditions along 1-direction on the faces CDEB and AFGM 1 2
(a)
text_image
tie constraint node a node b 2 1 boundary condition of 0.1 at node a, dof 1 boundary condition of 0.2 at node b, dof 1
(b)
Figure 35.6.1–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,” Section 35.3.1). 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.
Rigid body constraints and boundary conditions
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 35.6.1–6). In Figure 35.6.1–6(a) boundary conditions are specified at several nodes belonging to the rigid body. In Figure 35.6.1–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.
text_image
boundary conditions specified at nodes a, b, and c a b rigid body + c symmetry boundary conditions 2 1 3 face normal + rigid body reference node reference node 2 3 1 (a) (b)
Figure 35.6.1–6 Overconstraints due to 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 35.6.1–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.
Connector elements and rigid bodies
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 35.6.1–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 35.6.1–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.
text_image
reference node + rigid body composed of both ELSET1 and ELSET2 connector ELSET 1 ELSET 2 connector 2 3 1
(a)
flowchart
graph TD
A["BEAM connector"] -->|+| B["rigid body 1"]
B -->|+| C["reference node 1"]
C -->|connector| D["rigid body 2"]
D -->|+| E["reference node 2"]
(b)
Figure 35.6.1–7 Redundant constraints involving rigid bodies and connector elements.
When connector elements are placed between two rigid bodies (as in Figure 35.6.1–7(b)), the model may be redundantly constrained. As shown in Figure 35.6.1–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 may become underconstrained. To illustrate this situation, assume that in Figure 35.6.1–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.
Coupling constraints and rigid bodies
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 35.6.1–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.
flowchart
graph TD
A["1001"] --> B["1002"]
B --> C["1003"]
C --> D["1004"]
D --> E["1005"]
E --> F["101"]
F --> G["coupling reference node"]
H["rigid body"] --> I["102"]
I --> J["rigid body reference node"]
style A fill:#f9f,stroke:#333
style B fill:#f9f,stroke:#333
style C fill:#f9f,stroke:#333
style D fill:#f9f,stroke:#333
style E fill:#f9f,stroke:#333
style F fill:#f9f,stroke:#333
style G fill:#f9f,stroke:#333
Figure 35.6.1–8 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 may 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.
Coupling constraints and boundary conditions
When boundary conditions are specified at all nodes involved in a distributing coupling constraint, the model may become overconstrained. Abaqus/Standard will issue a warning message outlining the cause of the potential overconstraint.
Spot welds and rigid bodies
Potential overconstraints that may arise when a rigid body is involved in a mesh-independent spot weld definition are discussed in “Mesh-independent fasteners,” Section 35.3.4.
Overconstraints detected and resolved during analysis
There are numerous situations when contact interactions in combination with other constraint types may lead to overconstraints. Since contact status typically changes during the analysis, it is not possible to detect redundant constraints associated with contact in the model preprocessor. Instead, these checks are performed during the analysis. Due to the complexities associated with contact interactions, only a limited number of redundant constraint cases are resolved automatically.
Contact interactions and tie constraints
Redundant constraints are common in cases when slave nodes used in surface-based tie constraints (“Mesh tie constraints,” Section 35.3.1) are also slave nodes in contact, as illustrated in Figure 35.6.1–9. In Figure 35.6.1–9(a) nodes 5 and 9 are connected with a tie constraint, and both are in contact with a master surface. Since the two nodes are tied together, one of the contact constraints is redundant. A similar situation is presented in Figure 35.6.1–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. 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 slave node are recovered from the pressures and friction forces at the associated tie-independent nodes.
Deleting contact elements to remove overconstraints
Instead of letting Abaqus remove overconstraints by tying Lagrange multipliers, you can apply constraint controls that delete the contact elements associated with tied slave nodes. If you use this technique, contact-related output is not available for the tied slave nodes.
Input File Usage: *CONSTRAINT CONTROLS, DELETE SLAVE
text_image
distributed load on these faces tie constraint between these surfaces master surface completely fixed 14 1 5 9 6 13 11 12 2 3 1
(a)
text_image
tie constraint between faces ABCD and FGHE contact master surface
(b)
Figure 35.6.1–9 Redundant constraints arising from contact interactions and tie constraints.
Contact interactions and prescribed boundary conditions
Contact interactions and prescribed boundary conditions may lead to redundant constraints if either normal contact with the default “hard contact” formulation (“Contact pressure-overclosure
relationships,” Section 37.1.2) or frictional contact with the Lagrange multiplier formulation (see “Frictional behavior,” Section 37.1.5) 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 35.6.1–10 the fixed analytical rigid master surface is in contact with a slave 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 slave 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.
text_image
distributed load boundary condition in direction normal to the master surface
- reference node completely fixed rigid master surface
Figure 35.6.1–10 Overconstraints involving normal contact interactions and boundary conditions.
The contact and boundary conditions related to overconstraints are removed automatically only if the master 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 35.6.1–11. The symmetry boundary conditions combined with the Lagrange friction are redundant. The slave node is in contact and the tangent to the surface is in approximately the same direction as the specified boundary condition at the slave node. To avoid redundancy, at this node Abaqus/Standard will switch from the Lagrange friction formulation to the default penalty formulation (“Frictional behavior,” Section 37.1.5) if the motion of the master nodes is prescribed in the tangent direction.
text_image
symmetry boundary conditions on faces BDEF and ACHJ J I H A B G C D F nodes A, G, and C are overconstrained E 3 1 2 Lagrange friction
Figure 35.6.1–11 Lagrange friction and boundary conditions.
Overconstraints detected in the equation solver
All overconstraints that cannot be identified and resolved during preprocessing or during the analysis need to be detected by the equation solver. Examples include models with contact interactions where slave nodes are driven by specified boundary conditions into partially fixed rigid surfaces; contact with multiple master surfaces; closed-loop and multiple-loop mechanisms in which rigid bodies are connected by connector elements; and many more. By default, equation solver overconstraint checks are performed continuously during the analysis.
Abaqus/Standard will not resolve overconstraints detected by the equation solver. Instead, detailed messages with information regarding the kinematic constraints involved in the overconstraint will be issued. The message first identifies the nodes involved in either a consistent or an inconsistent overconstraint by using zero pivot information from the Gauss elimination in the solver (“Direct linear equation solver,” Section 6.1.5). A detailed message containing constraint information is then issued.
The 4-bar mechanism shown in Figure 35.6.1–12 illustrates this strategy. Four three-dimensional rigid bodies are defined as follows: the rigid body with reference node 10001 includes nodes 2 and 101; the rigid body with reference node 10002 includes nodes 3 and 102; the rigid body with reference node 10003 includes nodes 4 and 103; and the rigid body with reference node 10004 includes nodes 1 and 104. The four rigid bodies are connected with four JOIN and REVOLUTE combination connector elements defined as follows: element 20001 between nodes 1 and 101; element 20002 between nodes 2 and 102; element 20003 between nodes 3 and 103; and element 20004 between nodes 4 and 104. Each connector element enforces three translation and two rotation constraints (“Connectors: overview,” Section 31.1.1), and all four revolute axis directions are parallel. The bottom rigid body (with reference node 10004) is fixed. The motion of the bottom left REVOLUTE connector (element 20001) is prescribed to rotate the mechanism.
When Abaqus/Standard attempts to find a solution for this model, three zero pivots are identified in the first increment of the analysis suggesting that there are three constraints too many in the model.