38.2.1 Contact formulation for general contact in Abaqus/Explicit
Products: Abaqus/Explicit Abaqus/CAE
References
Overview
The contact formulation used with the general contact algorithm in Abaqus/Explicit:
includes the contact surface weighting, surface polarity, and the sliding formulation; and
can be applied selectively to particular regions within a general contact domain.
Specifying the contact formulation
Currently you can specify only the contact surface weighting and polarity for the general contact algorithm. The contact formulation propagates through all analysis steps in which the general contact interaction is active.
The surface names used to specify the regions where a nondefault contact formulation should be assigned do not have to correspond to the surface names used to specify the general contact domain. In many cases the contact interaction will be defined for a large domain, while a nondefault contact formulation will be assigned to a subset of this domain. Any contact formulation assignments for regions that fall outside the general contact domain will be ignored. The last assignment will take precedence if the specified regions overlap.
| Input File Usage: | *CONTACT FORMULATION |
This option must be used in conjunction with the *CONTACT option. It should appear at most once per step for each value of the TYPE parameter; the data line can be repeated as often as necessary to assign contact formulations to different regions. |
| Abaqus/CAE Usage: | Interaction module: Create Interaction: General contact (Explicit): Contact Formulation |
Contact surface weighting
Generally, contact constraints in a finite element model are applied in a discrete manner, meaning that for hard contact a node on one surface is constrained to not penetrate the other surface. In pure master-slave contact the node with the constraint is part of the slave surface and the surface with which it interacts is called the master surface. For balanced master-slave contact Abaqus/Explicit calculates the contact constraints twice for each set of surfaces in contact, in the form of penalty forces: once with the first surface acting as the master surface and once with the second surface acting as the master surface. The weighted average of the two corrections (or forces) is applied to the contact interaction.
Balanced master-slave contact minimizes the penetration of the contacting bodies and, thus, provides better enforcement of contact constraints and more accurate results in most cases. In pure master-slave contact the nodes on the master surface can, in principle, penetrate the slave surface unhindered (see Figure 38.2.1–1).
Figure 38.2.1–1 Master surface penetrations into the slave surface in pure master-slave contact due to coarse discretization.
The general contact algorithm in Abaqus/Explicit uses balanced master-slave weighting whenever possible; pure master-slave weighting is used for contact interactions involving node-based surfaces, which can act only as pure slave surfaces and for contact interactions involving analytical rigid surfaces, which can act only as pure master surfaces. Surface-based cohesive behavior also always uses a pure master-slave algorithm. However, you can choose to specify a pure master-slave weighting for other interactions as well.
There is no master-slave relationship for edge-to-edge contact; both contacting edges are given equal weighting.
Specifying pure master-slave weighting for node-to-face contact
You can specify that a general contact interaction should use pure master-slave weighting for node-to-face contact. This specification has no effect on edge-to-edge contact and cannot be used to make a node-based surface act as a master surface. When two originally flat surfaces contact one another, a more uniform penetration distance distribution (and consequently pressure distribution) may result with pure master-slave weighting where the more refined surface acts as the slave surface as compared to balanced master-slave weighting. This can be particularly evident if the mesh densities of the contacting surfaces differ significantly—with balanced weighting the contact penetrations will be smaller near the nodes of the coarsely meshed surface.
Abaqus/Explicit will automatically generate contact exclusions for the master-slave orientation opposite to that specified; therefore, node-to-face self-contact will be excluded for any regions of the two surfaces that overlap. For example, specifying that the general contact interaction between surf_A and surf_B should use pure master-slave weighting with surf_A considered to be the slave surface would result in exclusions being generated internally for faces of surf_A contacting nodes of surf_B; node-to-face self-contact would be excluded for the region of overlap between surf_A and surf_B. A warning message will be issued if the second surface name is omitted or is the same as the first surface name since this input would result in the exclusion of node–face self-contact for the surface.
| Input File Usage: | Use the following option to indicate that the first surface should be considered the slave surface (default): |
*CONTACT FORMULATION, TYPE=PURE MASTER-SLAVE surf_1, surf_2, SLAVE Use the following option to indicate that the first surface should be considered the master surface: *CONTACT FORMULATION, TYPE=PURE MASTER-SLAVE surf_1, surf_2, MASTER If the first surface name is omitted, a default surface that encompasses the entire general contact domain is assumed. The second surface name must be specified. |
| Abaqus/CAE Usage: | Interaction module: Create Interaction: General contact (Explicit): Contact Formulation: Pure master-slave assignments: Edit: select the surfaces in the columns on the left, and click the arrows in the middle to transfer them to the list of master-slave assignments. |
In the First Surface Type column, enter SLAVE to indicate that the first surface should be considered the slave surface, and enter MASTER to indicate that the first surface should be considered the master surface. |
Contact surface polarity
By default, general contact considers both sides of all double-sided elements in surfaces specified to be included for contact purposes (side labels of double-sided elements are ignored). This default can be overridden for node-to-face and Eulerian-Lagrangian contact and in some cases results in more accurate enforcement of contact.
Surface polarity is not considered for edge-to-edge contact, including edges activated on faces of solid elements.
Specifying surface polarity for node-to-face and Eulerian-Lagrangian contact
Changing the polarity of double-sided elements forces the contact algorithm to treat them as if they were solid elements. More accuracy may be gained by converting double-sided elements to single-sided if there is a chance that slave nodes may be “caught” behind the surface in node-to-face contact or if material contained on one side of a double-sided surface leaks to the other side in Eulerian-Lagrangian contact. Improvements in performance and memory use may also be observed with Eulerian-Lagrangian contact if double-sided Lagrangian surfaces are converted to single-sided for contact with all Eulerian material surfaces.
| Input File Usage: | Use the following option to indicate that the sides of the (double-sided) elements specified in the second surface's definition should be considered for contact with the first surface: |
*CONTACT FORMULATION, TYPE=POLARITY surf_1, surf_2 Use the following option to indicate that the SPOS side of the (double-sided) elements in the second surface should be considered for contact with the first surface: *CONTACT FORMULATION, TYPE=POLARITY surf_1, surf_2, SPOS Use the following option to indicate that the SNEG side of the (double-sided) elements in the second surface should be considered for contact with the first surface: *CONTACT FORMULATION, TYPE=POLARITY surf_1, surf_2, SNEG Use the following option to indicate that both sides of the (double-sided) elements in the second surface should be considered for contact with the first surface: *CONTACT FORMULATION, TYPE=POLARITY surf_1, surf_2, TWO SIDED If the first surface name is omitted, a default surface that encompasses the entire general contact domain is assumed. The second surface name must be specified. |
Sliding formulation
Currently only the finite-sliding formulation is available for general contact in Abaqus/Explicit. This formulation allows for arbitrary separation, sliding, and rotation of the surfaces in contact. For cases in which small-sliding or infinitesimal-sliding assumptions would be preferred, the contact pair algorithm should be used (see “Contact formulations for contact pairs in Abaqus/Explicit,” Section 38.2.2).
Abaqus/Explicit is designed to simulate highly nonlinear events or processes. Because it is possible for a node on one surface to contact any of the facets on the opposite surface, Abaqus/Explicit must use sophisticated search algorithms for tracking the motions of the surfaces. The finite-sliding contact search algorithm is designed to be robust, yet computationally efficient. This algorithm assumes that the incremental relative tangential motion between surfaces does not significantly exceed the dimensions of the master surface facets, but there is no limit to the overall relative motion between surfaces. It is rare for the incremental motion to exceed the facet size because of the small time increment used in explicit dynamic analyses. In cases involving relative surface velocities that exceed material wave speeds it may be necessary to reduce the time increment.
The contact search algorithm uses a global search when a contact interaction is first introduced, and a hierarchical global/local search algorithm is used thereafter. No user control of the search algorithm is needed.
Local tangent directions for contact
Local tangent directions for contact provide a reference frame for select general contact output variables in Abaqus/Explicit (see “Defining general contact interactions in Abaqus/Explicit,” Section 36.4.1). These local tangent directions are separate from local coordinate systems associated with user subroutines VFRICTION and VUINTERACTION. Abaqus/Explicit establishes and updates the orientation of the first local contact tangent direction, 
, at slave and edge nodes according to the logic described below for different contact formulation types within general contact. The orientation of the second local tangent direction, 
, is found as the cross product of the contact normal direction, 
with . A change in the predominant contact formulation type that is active at a node may lead to a sudden change in the local tangent directions.
Finite-sliding, node-to-surface formulation for non-analytical surfaces: The -direction is initialized at a slave node upon first contact using the standard convention for calculating a first local surface tangent direction (see “Conventions,” Section 1.2.2). In subsequent increments, if the slave node belongs to an element-based surface, the -direction rotates with the slave surface for geometrically nonlinear analyses; otherwise, the standard convention is used.
Finite-sliding, node-to-surface formulation with an analytical surface: The -direction for contact is initialized at a slave node upon first contact to be aligned with the convention for the -direction of the analytical rigid surface discussed in “Analytical rigid surface definition,” Section 2.3.4 at the point of contact. In subsequent increments, the -direction for contact at a slave node will evolve such that it continues to be aligned with the -direction of the analytical rigid surface at the current point of contact.
Finite-sliding, edge-to-edge formulation: The -direction for an edge-to-edge contact constraint is initialized upon first contact to be in the axial direction of one of the edges involved in the contact and will evolve to remain aligned with the axial direction of this edge until a local transition to another edge occurs, and then the axial direction of that edge will be adopted as the -direction.
Local tangent directions associated with slave nodes will often differ across a contact interface. For example, respective local -directions (CTANDIR1) on opposite sides of an interface will evolve differently if surface rotations across the interface are not the same. The respective local -directions (CTANDIR2) on opposite sides of an interface are typically in opposing directions initially, due to slave nodes on opposite sides of an interface having opposing contact normal directions.