김경종
12 KiB
flowchart
graph TD
A["element 20001"] -->|1| B["10001"]
B -->|x| C["10002"]
C -->|x| D["10003"]
D -->|x| E["10004"]
E -->|1| F["element 20004"]
F -->|1| G["element 20003"]
G -->|3| H["element 20002"]
H -->|2| A
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
style H fill:#f9f,stroke:#333
note right of A "connector motion"
note right of B "10001"
note right of C "10002"
note right of D "10003"
note right of E "10004 (fixed)"
Figure 35.6.1–12 Hard-to-detect redundant constraints.
Eventually, one would have to remove three constraints to render the model properly constrained. In this simple example a count of the degrees of freedom and constraints confirms the number of overconstraints, as follows. There are four rigid bodies in the model, with a total of 24 degrees of freedom. The reference node 10004 is completely fixed with a boundary condition, constraining six degrees of freedom; and the prescribed connector motion enforces one rotational constraint, constraining one degree of freedom. Hence, there are 17 degrees of freedom remaining. Each of the four connector elements enforces five constraints, for a total of 20 constraints. Thus, there are three constraints too many in the model, which matches the number of zero pivots identified by the equation solver. To help you identify the constraints that should be removed, the following message is produced in the message (.msg) file outlining the chains of constraints that generated the overconstraint:
***WARNING: SOLVER PROBLEM. ZERO PIVOT WHEN PROCESSING ELEMENT 20004INTERNAL NODE 1 D.O.F. 4
OVERCONSTRAINT CHECKS: An overconstraint was detected at one of the Lagrange multipliers associated with element 20004. There are multiple constraints applied directly or chained constraints that are applied indirectly to this element. The following is a list of nodes and chained constraints between these nodes that most likely lead to the detected overconstraint.
LAGRANGE MULTIPLIER: 4 <-> 104: connector element 20004 type JOIN REVOLUTE constraining 3 translations and 2 rotations
..4 -> 10003: *RIGID BODY (or *COUPLING-KINEMATIC)
....10003 -> 103: *RIGID BODY (or *COUPLING-KINEMATIC)
....103 -> 3: connector element 20003 type JOIN REVOLUTE
constraining 3 translations and 2 rotations
....3 -> 10002: *RIGID BODY (or *COUPLING-KINEMATIC)
....10002 -> 102: *RIGID BODY (or *COUPLING-KINEMATIC)
....102 -> 2: connector element 20002 type JOIN REVOLUTE
constraining 3 translations and 2 rotations
....2 -> 10001: *RIGID BODY (or *COUPLING-KINEMATIC)
....10001 -> 101: *RIGID BODY (or *COUPLING-KINEMATIC)
....101 -> 1: connector element 20001 type
JOIN REVOLUTE constraining 3
translations and 2 rotations
....1 -> 10004: *RIGID BODY (or *COUPLING-KINEMATIC)
....10004 -> *BOUNDARY in degrees of freedom
1 2 3 4 5 6
....10004 -> 104: *RIGID BODY
(or *COUPLING-KINEMATIC)
....1 -> 101: connector element 20001 with
*CONNECTOR MOTION in components 4
Please analyze these constraint loops and remove unnecessary constraints.
First, the message identifies the user-defined or, in this case, the internally defined (Lagrange multiplier) node at which a zero pivot was identified. A typical line in this output issues information related to one constraint. For example, the first line in this output
LAGRANGE MULTIPLIER: 4 <-> 104: connector element 20004 type JOIN REVOLUTE constraining 3 translations and 2 rotations
informs you that the Lagrange multiplier on which the zero pivot occurs enforces one of the five constraints (JOIN and REVOLUTE) associated with connector element 20004 between user-defined nodes 4 and 104. Each of the subsequent lines conveys information related to one constraint in the chains of constraints originating at the zero pivot node or in chains adjacent to them. For example, the line
....10003 -> 103: *RIGID BODY (or *COUPLING - KINEMATIC)
informs you that there is a rigid body constraint between nodes 10003 and 103, while the line
....10004 -> *BOUNDARY in degrees of freedom 1 2 3 4 5 6
states that there is a boundary condition constraint fixing degrees of freedom 1 through 6 at node 10004.
Indentation levels (the dots in front of the node numbers) identify links in a chain of constraints. Each time a constraint is found to link another node in a particular chain, the indentation is increased by two dots and the constraint information is printed out. For example, starting from the top of the
message, the Lagrange multiplier is connected to node 4, node 4 is connected to node 10003, node 10003 is connected to node 103, and so on. When the indentation on a certain line is less than or equal to the indentation on the previous line, a chain of constraints has ended on the previous line. For example, a chain has ended on the line
10004 -> *BOUNDARY in degrees of freedom
1 2 3 4 5 6
since the next line has equal indentation.
Three chains of constraints (in correspondence with the three zero pivots that were found) that most likely generated the overconstraint can be identified in the model above. Starting from the top, one can first identify a chain of constraints that terminates in a boundary condition (ground):
Lagrange multiplier: 4 -> 10003 -> 103 -> 3 -> 10002 -> 2 -> 10001 -> 101 -> 1 -> 10004 -> *BOUNDARY
Since the indentation of the two lines starting with node 10004 is the same, one should expect another chain of constraints to include the constraint output on the second of the two lines. Indeed, one can identify a closed loop of constraints:
Lagrange multiplier : 4-> 10003 -> 103 -> 3 -> 10002 -> 2 -> 10001 -> 101 -> 1 -> 10004 -> 104 <-> 4
Finally, since the two lines starting with node 1 have the same indentation, one expects that a separate chain of constraints will include the last line in the output. A third (closed) loop
101 -> 1 -> 101
is identified.
If the chains of constraints terminate in a free end (not ending in a constraint), the chain does not have any contribution in generating the overconstraint. There are no such chains in this example.
Correcting an overconstrained model
A node set containing all the nodes in the chains of constraints associated with a particular zero pivot is generated automatically and can be displayed in the Visualization module of Abaqus/CAE.
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,” Section 31.2.1).
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.
Controlling the overconstraint checks
By default, Abaqus/Standard will attempt to remove as many redundant constraints as possible, as discussed in the sections above. When it is not possible to remove a redundant constraint or an inconsistent overconstraint is detected, a detailed message is issued identifying the constraints contributing to the overconstraint. You can modify this default behavior by prescribing constraint controls for the model or the step.
Overconstraints may produce damaging and unpredictable behavior. Therefore, it is strongly recommended that overconstraint checking be used in both the preprocessor and during the analysis at least during the first running of a model. Furthermore, it is recommended that the original model be changed to correct any overconstraints identified by Abaqus/Standard. Only after establishing confidence that the model is free of overconstraints should constraint checks be turned off. The only advantage of turning off the constraint checks is a minor speedup of the analysis.
Bypassing the overconstraint checks
The overconstraint checks performed during input file preprocessing and during the analysis can be bypassed. Bypassing these checks is not recommended, as it may 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.
Input File Usage: *CONSTRAINT CONTROLS, NO CHECKS
Preventing automatic redundant constraint resolution
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.
Input File Usage: *CONSTRAINT CONTROLS, NO CHANGES
Changing the frequency of the overconstraint checks
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.
Input File Usage: *CONSTRAINT CONTROLS, CHECK FREQUENCY=n
Stopping the analysis when overconstraints are detected
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.
Input File Usage: Use one of the following options:
*CONSTRAINT CONTROLS, TERMINATE ANALYSIS=FIRST OCCURRENCE
*CONSTRAINT CONTROLS, TERMINATE ANALYSIS=CONVERGED
Part IX: Interactions
• Chapter 36, “Defining Contact Interactions”
• Chapter 37, “Contact Property Models”
• Chapter 38, “Contact Formulations and Numerical Methods”
• Chapter 39, “Contact Difficulties and Diagnostics”
• Chapter 40, “Contact Elements in Abaqus/Standard”
• Chapter 41, “Defining Cavity Radiation in Abaqus/Standard”
36. Defining Contact Interactions
Overview 36.1
Defining general contact in Abaqus/Standard 36.2
Defining contact pairs in Abaqus/Standard 36.3
Defining general contact in Abaqus/Explicit 36.4
Defining contact pairs in Abaqus/Explicit 36.5