Files
MultiPhysicsVault/.raw/AbaqusAnalysisUserGuide5/AbaqusAnalysisUserGuide5_038.md
T
김경종 b7f84e1c0f
Tests / Hermetic test suite (push) Has been cancelled
Tests / Skill frontmatter validation (push) Has been cancelled
add documents
2026-05-29 15:59:56 +09:00

14 KiB
Raw Blame History

35.5 Element end release

• “Element end release,” Section 35.5.1

35.5.1 ELEMENT END RELEASE

Product: Abaqus/Standard

References

• “Kinematic constraints: overview,” Section 35.1.1
• *RELEASE

Overview

Element end release:

• allows a rotational degree of freedom or a combination of rotational degrees of freedom to be released at one or both ends of an element or element set;
• can be used in geometrically linear or nonlinear analysis; and
• is available only for beam and pipe elements in Abaqus/Standard.

Introduction

Element end release is used to model hinged connections (hinged in one, two, or three orthogonal directions) at one or both ends of the element. By releasing rotational degrees of freedom, an element end is allowed to rotate freely relative to the node about the chosen degrees of freedom. Any rotational degrees of freedom that are not released are shared with the node. You must be careful not to release a given degree of freedom at a node for all elements that share that node; otherwise, the node has no stiffness for that degree of freedom and Abaqus/Standard issues zero pivot warning messages.

Element end release operates on the element local degrees of freedom. See “Beam element crosssection orientation,” Section 29.3.4, for a definition of the local axes ( n _ { 1 } , n _ { 2 } , t ) for beam-type elements. The rotational degrees of freedom affected by the release are the rotation about the local n _ { 1 } { \mathrm { - } } { \mathrm { a x i s } } . , the rotation about the local n _ { \mathrm { { 2 } } } { \mathrm { - } } { \mathrm { { a x i s } } } , and the rotation about the local t-axis for beams in space. For beams in a plane, only the rotation about the local -axis is active (which coincides with rotations about the negative global z-axis).

Equivalent MPCs

If only one rotational degree of freedom is released, the kinematic constraint is equivalent to MPC type REVOLUTE plus MPC type PIN between two nodes. If two rotational degrees of freedom are released, the kinematic constraint is equivalent to MPC type UNIVERSAL plus MPC type PIN. If all rotational degrees of freedom are released, the kinematic constraint is equivalent to MPC type PIN. See “General multi-point constraints,” Section 35.2.2, for details.

Identifying the element end involved in the release

Either element sets or individual elements can be specified for a release definition. Degrees of freedom can be released at the first, second, or first and second ends of an element. The first end of the element, S1, is node 1 on the element as defined by the element connectivity; the second end, S2, is the last node (node 2 or 3, as appropriate) on the element. See “Beam element library,” Section 29.3.8, for a definition of the node ordering for beam elements.

Identifying the local rotational degrees of freedom involved in the release

Rotation combination codes rather than degrees of freedom are specified to identify the rotational degrees of freedom involved in the release.

M1 refers to the rotation about the -axis,

M2 refers to the rotation about the -axis,

M1-M2 refers to a combination of rotational degrees of freedom about the -axis and the -axis, T refers to the rotation about the t-axis,

M1-T refers to a combination of rotational degrees of freedom about the -axis and the t-axis,

M2-T refers to a combination of rotational degrees of freedom about the -axis and the t-axis, and

ALLM represents a combination of all the rotational degrees of freedom (i.e., M1, M2, and T).

Input File Usage: *RELEASE

element number or element set, element end ID, release combination code

For example, to release the rotational degree of freedom about the -axis at the first end of element 10 and all the rotational degrees of freedom at the second end of the element, use the following input:

*RELEASE

10, S1, M1

10, S2, ALLM

Use with transformed coordinate systems

Transformations applied to released nodes (“Transformed coordinate systems,” Section 2.1.5) have no influence on the release. The release operates on the local degrees of freedom for the element.

Reading the data from an alternate input file

The data for a release definition can be contained in a separate input file.

Input File Usage: *RELEASE, INPUT=file_name

If the INPUT parameter is omitted, it is assumed that the data lines follow the keyword line.

35.6 Overconstraint checks

• “Overconstraint checks,” Section 35.6.1

35.6.1 OVERCONSTRAINT CHECKS

Product: Abaqus/Standard

References

• “Rigid body definition,” Section 2.4.1
• “Connectors: overview,” Section 31.1.1
• “Boundary conditions in Abaqus/Standard and Abaqus/Explicit,” Section 34.3.1
• “General multi-point constraints,” Section 35.2.2
• “Mesh tie constraints,” Section 35.3.1
• “Coupling constraints,” Section 35.3.2
• “Mesh-independent fasteners,” Section 35.3.4
• “Defining contact pairs in Abaqus/Standard,” Section 36.3.1
• *BASE MOTION
• *CONSTRAINT CONTROLS

Overview

An overconstraint means applying multiple consistent or inconsistent kinematic constraints. Many models have nodal degrees of freedom that are overconstrained. Such overconstraints may lead to inaccurate solutions or nonconvergence. Common examples of situations that may lead to overconstraints include (but are not limited to):

• contact slave nodes that are involved in boundary conditions or multi-point constraints;
• edges of surfaces involved in a surface-based tie constraint that are included in contact slave surfaces or have symmetry boundary conditions; and
• boundary conditions applied to nodes already involved in coupling or rigid body constraints.

The overconstraint checks performed in Abaqus/Standard:

• check for overconstraints caused by combinations of the following: base motions, boundary conditions, contact pairs, coupling constraints, linear constraint equations, mesh-independent spot welds, multi-point constraints, rigid body constraints, and surface-based tie constraints;
• check for overconstraints resulting from kinematic constraints introduced through connector elements, coupling elements, special-purpose contact elements, and elements with incompressible material behavior;
• identify through detailed messages the constraints that cause overconstraints;
• automatically resolve a limited set of consistent overconstraints detected during model preprocessing and during an Abaqus/Standard analysis;

• use the equation solver to detect overconstraints that cannot be resolved automatically; and
• can have the default behavior modified.

Overconstraints: general remarks

In general, the term overconstraint refers to multiple constraints acting on the same degree of freedom. Overconstraints are then categorized as consistent (if all the constraints are compatible with each other) or inconsistent (if the constraints are incompatible with each other). Consistent overconstraints are also called redundant constraints, and inconsistent overconstraints are also called conflicting constraints.

In Abaqus/Standard the following types of constraints, in combination, may lead to overconstraints:

• boundary conditions or base motions,
• contact pairs,
• coupling constraints,
• mesh-independent spot welds,
• multi-point constraints or linear constraint equations,
• surface-based tie constraints, and
• rigid body constraints.

In addition to these constraints the following elements impose kinematic constraints and, when used in combination with each other or with the above constraints, may lead to overconstraints:

• connector elements,
• special-purpose contact elements, and
• hybrid elements for incompressible material response.

An illustration of several consistent overconstraints is given in Figure 35.6.11. The upper block is built from three separately meshed regions, which are connected together using a surface-based tie constraint. This block is in contact with the lower rigid block, which is made rigid by specifying a rigid body constraint. The rigid blocks reference node is fixed. Symmetry boundary conditions are used at the left edge of the upper block, and rough friction is defined for the surface interaction between the upper and lower blocks. The following redundant constraints can be identified:

• Intersecting tie constraints: At (A) three nodes share the same location, and their relative motions are constrained by two surface-based tie constraints (one vertical and one horizontal). Only two constraints (two dependent nodes and one independent node) are needed to fully constrain the motion of the three nodes, but three constraints are generated internally (one for the horizontal tie constraint and two for the vertical one). Therefore, one redundant constraint exists.

• Tie constraint and symmetry boundary condition: At (B) nodes 141 and 151 have their motion constrained horizontally by the symmetry boundary condition, but their relative motion is also constrained by the surface-based tie constraint. Therefore, one redundant constraint exists.

• Rough friction and symmetry boundary condition: At (C) node 101 is constrained horizontally by the symmetry boundary condition. The rough friction contact acts in the same direction as the boundary condition. Therefore, one redundant constraint exists.

text_image

reference node rigid punch tie constraints (A) symmetry boundary conditions (B) 141 501 423 151 625 101 801 301 (C) rough friction (C) rigid body reference node for lower block symmetry line (D)

Figure 35.6.11 Model with redundant constraints.

• Tie constraint and contact interactions: At (D) nodes 801 and 301 are involved in the surface-based tie constraint, but two contact constraints (one at each node) act in the vertical direction. Therefore, one redundant constraint exists.

Even in this simple model the number of redundant constraints is surprisingly large. If not appropriately accounted for, the redundant constraints can lead to convergence difficulties, even nonconvergence. Moreover, in the cases when a solution is obtained (despite the convergence difficulties), the reported reaction forces and contact pressures may be inaccurate.

Abaqus/Standard checks for the inappropriate use of combinations of constraints for the majority of constraint and element types listed in this section. Depending on the complexity of the constraints involved, Abaqus/Standard identifies three classes of consistent and inconsistent overconstraints.

Overconstraints detected in the model preprocessor

Many relatively simple overconstraints can be identified by inspecting the constraints defined at a node. If a consistent overconstraint is detected, the unnecessary constraints are eliminated automatically and a warning message is generated. If the overconstraints are inconsistent, the analysis is stopped and an error message is generated.

Overconstraints detected and resolved in an Abaqus/Standard analysis

Some overconstraints involving contact interactions may become overconstrained only during an analysis due to changes in contact status. Certain of these cases are detectable and eliminated automatically by Abaqus/Standard. Appropriate messages are issued.

Overconstraints detected by the equation solver

Many overconstraints involve complex interactions between various constraint definitions and element types. Automatic resolution of these situations may not be possible. In such cases the equation solver will detect the overconstraint, and a detailed message listing potential causes of the problem will be issued.

Overconstraints detected in the model preprocessor

In this section we consider overconstraints that involve two or more of the following:

• surface-based tie constraints,
• rigid body constraints,
• boundary conditions, and
• connector elements.

While the number of cases handled automatically in the model preprocessor is limited, many oftenencountered situations are corrected. The list of overconstraints to be resolved automatically in the preprocessor is organized based on the constraint types involved. Each case is illustrated by examples.

Intersecting tie constraints

Examples of intersecting tie constraint definitions are shown in Figure 35.6.12. 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.

Tie constraint inside a rigid body constraint

An example of a tie constraint inside a rigid body constraint is shown in Figure 35.6.13(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 bodys reference node, the tie constraint is redundant. The tie constraint definition is removed from the model.