Purpose of User Subroutines UINTER, VUINTER, and VUINTERACTION
User subroutines
UINTER,
VUINTER, and
VUINTERACTION provide a very general interface for you to define the
constitutive behavior across the interface between two surfaces. These
subroutines replace all built-in interfacial constitutive behavior models;
hence, no other contact property definitions (e.g., friction, thermal
conductance, etc.) can be specified in conjunction with them.
In a stress/displacement analysis you must define the stresses, both normal and tangential, at
the secondary node (or points on the secondary surface) at the current point in time. In a
coupled temperature-displacement analysis and a coupled thermal-electrical-structural
analysis you must also define the heat flux across the interface. The constitutive
calculation thus involves computing the stresses and heat fluxes based on the increments in
relative position of the secondary node with respect to the main surface (which act as
strains in this context), temperature at the surface, and predefined field variables. The
calculations would typically involve solution-dependent state variables, which can be
updated inside these routines. If contact damping is to be included in the interfacial
constitutive model, you must include the damping contribution in the stress definition.
When a user subroutine is used to define the interfacial constitutive behavior, all decisions
regarding the contact status of a secondary node must be made inside the subroutine based on
the information provided. You can make such decisions based on the values of the relative
position of the point on the secondary surface with respect to the main surface and
appropriately defined solution-dependent state variables. Thus, usage of this feature
involves not only developing a constitutive behavior of the interface but also developing
conditions under which contact is active at a given point on the secondary surface. The
interface is always assumed to be massless.
User subroutine UINTER will be called for each
contact constraint location of affected contact pairs in each iteration of an Abaqus/Standard analysis. The input to this user subroutine includes the current relative position of a
particular constraint point on the secondary surface with respect to the corresponding
closest point on the main surface, as well as the incremental relative motion between these
two points. Values of temperature and field variables at the constraint point on the
secondary surface and the corresponding closest point on the main surface and several other
variables are also provided as input. In addition to defining the contact stress or heat
flux, appropriate Jacobian terms must also be defined to ensure proper convergence
characteristics in Abaqus/Standard.
User subroutine VUINTER will be called multiple
times for the affected contact pairs in each time increment of an Abaqus/Explicit analysis. All secondary nodes are processed in each call to VUINTER, whereas only a single
constraint is processed in each call to UINTER. Similar input is provided to
VUINTER as UINTER.
User subroutine
VUINTERACTION will be called multiple times for each interacting surface
in each time increment of an
Abaqus/Explicit
analysis. Points of potential contact for a given interaction are processed in
blocks in calls to
VUINTERACTION. Similar input is provided to
VUINTERACTION as
VUINTER.
Interfacial Constants
You must specify the number of interfacial constants that are needed in user subroutine UINTER, VUINTER, or VUINTERACTION; and you must provide
values for all these constants. All surface constitutive behavior calculations and all
decisions regarding the contact status at a secondary node (or a point on the secondary
surface in question) must be programmed in the user subroutine. Any other contact property
definitions included in the analysis are reported as an error.
Tracking Thickness When VUINTER or VUINTERACTION Is Used
Computations to determine the precise distance to a main surface are avoided if a secondary node
can be easily determined to be separated from the main surface, accounting for all thickness
effects and built-in contact property models, by more than a threshold distance called the
tracking thickness. Abaqus/Explicit uses an internal default value for the tracking thickness. If a built-in contact property
model is in effect, the tracking thickness is quite small to help reduce computation time.
However, if user subroutine VUINTER or user subroutine VUINTERACTION is in effect, the
default tracking thickness is infinite so that all secondary nodes are supplied to the user
subroutines as having potential interactions. Alternatively, you can specify the tracking
thickness in conjunction with a user-defined surface interaction model. In this case
secondary nodes whose proximity to their main surfaces are within this thickness are
available for user-defined interactions. Use of a user-specified tracking thickness is
supported only with node-to-surface contact and not with edge-to-edge contact.
Interfacial State
Constitutive models used to define the interfacial behavior may require the
storage of solution-dependent state variables. You must allocate storage space
for these variables by indicating the number of variables. There is no
restriction on the number of state variables associated with a user-defined
constitutive behavior for the interface.
User subroutine UINTER is called for points on the
secondary surface at each iteration of every increment. User subroutine VUINTER is called in every time
increment for each main-secondary view of each contact pair it affects, as discussed
earlier. User subroutine VUINTERACTION is called in every
time increment for each pair of surfaces actively interacting, as discussed earlier. Each
subroutine is provided with the state of the secondary node or potential contact point at
the start of the increment (the state includes stress, flux, solution-dependent state
variables, temperature, and any predefined field variables) and with the increments in
temperature, predefined state variables, relative position, and time.
Use with the Unsymmetric Equation Solver in Abaqus/Standard
If the constitutive Jacobian matrix, ,
is not symmetric, you should invoke the unsymmetric equation solution
capability in
Abaqus/Standard
(see
Defining an Analysis).
Defining the Contact Status in Abaqus/Standard
In addition to defining the constitutive behavior, in Abaqus/Standard you may also update the flags LOPENCLOSE,
LSTATE, and LSDI. The flag
LOPENCLOSE is useful when UINTER is used to model standard
contact between two surfaces (similar to the default hard contact in Abaqus). It should be set to 0 to indicate an open status and to 1 to indicate a closed status.
At the beginning of the analysis it is set to −1 before UINTER is called. A change in this
flag from one iteration to the next will have two consequences. It will result in output
related to the change in contact status if detailed contact output has been requested to the
message file (see The Abaqus/Standard Message File), and it will
also trigger a severe discontinuity iteration. The flag
LSTATE can be used to store the current contact status of
the points on the secondary surface in non-standard situations where a simple open/close
status is not appropriate. An example of such a situation is debonding, where three
different states can be defined—fully bonded, partially bonded or debonding, and fully
debonded. You can assign an integer to each of these states and set
LSTATE accordingly. At the beginning of the analysis
LSTATE is set to −1 before UINTER is called. When this flag is
used and it changes from one iteration to the next, you can output messages to the message
file (unit 7) related to such a change in state directly from user subroutine UINTER. The flag
LPRINT is provided to allow you to output messages related
to change in contact status only when you request detailed contact output to the message
file. In such a situation the LSDI flag may be set to 1 to
trigger a severe discontinuity iteration (this issue is discussed in detail later).
An example of a situation where both the flags
LOPENCLOSE and
LSTATE can be used arises in the modeling of
debonding between two surfaces. When the surface is in a state of transition
from bonded to debonded, the flag LSTATE may be
used, while the flag LOPENCLOSE may be left to
its original value of −1. However, once complete debonding has taken place, the
contact between the two surfaces may be modeled using standard hard contact. In
that situation the LSTATE flag may be set to −1,
and the LOPENCLOSE flag used. Any time one of
these two flags is set to −1,
Abaqus/Standard
assumes that it is not being used. A change of these flags from some other
value to −1 does not result in contact-status related output or severe
discontinuity iterations. Similarly, a change of these flags from −1 to some
other value will not result in contact-status related output or severe
discontinuity iterations.
If these flags are not used, there will be no output related to change in
contact status unless you decide to output messages that are not based on these
flags directly from
UINTER.
Severe Discontinuity Iterations in Abaqus/Standard
Abaqus/Standard
classifies iterations in which the contact state at the end of the iteration is
different from the state assumed for that iteration as severe discontinuity
iterations. The treatment of severe discontinuity iterations by
Abaqus/Standard
is discussed in
Severe Discontinuities in Abaqus/Standard.
When you define the interfacial constitutive behavior through user subroutine
UINTER and do not use the
LOPENCLOSE flag, it is your responsibility to
provide
Abaqus/Standard
with input on how an iteration should be treated. The flag
LSDI is provided in user subroutine
UINTER for this purpose. It is set to 0 before each call to
UINTER; you should set it to 1 to treat the current iteration as
a severe discontinuity iteration. If the
LOPENCLOSE flag is used, the value of this flag
alone determines whether a severe discontinuity iteration is necessary or not,
and the LSDI flag is ignored.
Use with Contact in Abaqus/Explicit
The penalty contact algorithm must be used with user subroutines
VUINTER and
VUINTERACTION; see
Penalty Contact Algorithm.
When VUINTER is used and balanced
main-secondary contact is specified (that is, the contact pair weighting factor is not equal
to 0.0 or 1.0), VUINTER will be called for each
surface in the contact pair that can act as a secondary surface. The forces and fluxes
defined in VUINTER will be multiplied by the
weight value for the main-secondary view before they are applied.
Effects on Solution Time in Abaqus/Explicit
Abaqus/Explicit accounts for the contact stiffness and conductance in the stable time increment
calculation. Specifying stresses and fluxes in the user subroutine that correspond to large
contact stiffness (e.g., large slope of contact pressure versus penetration) and large
contact conductance will cause a significant drop in the stable time increment and,
therefore, an increase in the solution time. Tangent stiffnesses and conductances are
determined by Abaqus/Explicit using a finite difference method. User subroutine VUINTER is called three times per
increment for each main-secondary view of each two-dimensional contact pair that references
it and four times per increment for each three-dimensional contact pair that references it.
User subroutine VUINTERACTION is called four times
per increment for each active surface interaction that references it. The user subroutines
are called once with the actual configuration and subsequently with perturbed configurations
based on displacement perturbations in the normal direction, the
tangential direction, and, in three-dimensional cases, the
tangential direction, respectively (see the local coordinate system
discussion in VUINTER and VUINTERACTION for an
explanation of how the
and
directions are defined). For example, each component of contact stiffness
is computed as a difference in contact stress divided by a difference in relative position.
You do not have access to the computed values of contact stiffness and conductance, but you
can control the constitutive behavior of the model. Estimated default penalty stiffness (and
conductance) values are provided to the user subroutines for comparison purposes. Contact
stiffnesses or conductances that exceed the default penalty values can significantly reduce
the time increment size. The default penalty stiffnesses and conductances are based on an
assumption that all secondary nodes are in contact. In the case of VUINTER, if only a fraction of the
secondary nodes are in contact, higher penalties than are reported in VUINTER would be assigned in some
cases with the default penalty algorithm.
Any changes to state variables are ignored for the perturbation calls.
In the case of VUINTER there can be significant
additional CPU expense associated with contact tracking. Since the contact state is unknown
on entry to VUINTER, all nodes on the secondary
surface must be tracked in every increment. This can increase the cost of an analysis
significantly compared to the contact models in Abaqus/Explicit if a large proportion of the secondary nodes are not involved in contact.
In the case of
VUINTERACTION there can be significant additional CPU expense associated
with contact tracking only if the tracking thickness is large compared to the
element facet size on contacting surfaces.
Use with Other Subroutines
Any other user subroutine that does not deal with constitutive behavior
across an interface can be used in conjunction with
UINTER,
VUINTER, or
VUINTERACTION.
For example, user subroutines
UMAT and
UMATHT can be used in conjunction with
UINTER to define the constitutive mechanical and thermal
behaviors of the material underlying the contact surfaces. User subroutine
VUMAT and
VUMATHT can be used in conjunction with
VUINTER to define the constitutive mechanical and thermal
behaviors of the material underlying the contact surfaces. However, user
subroutines
FRIC,
GAPCON, and
GAPELECTR—available in
Abaqus/Standard for
defining mechanical, thermal, and electrical interactions between surfaces—can
be used in conjunction with
UINTER only if they are referenced on separate surface
interactions. The same restriction applies to user subroutine
VFRIC used in conjunction with
VUINTER and to user subroutines
VFRICTION or
VFRIC_COEF used in conjunction with
VUINTERACTION.
Use with Contact Controls
In
Abaqus/Standard
contact controls will not have any effect when used at an interface whose
constitutive behavior is defined through user subroutine
UINTER.
In
Abaqus/Explicit
contact controls can be specified for a contact pair referencing a user-defined
surface interaction. In the case of user subroutine
VUINTERACTION the default penalty stiffness argument includes any scale
factor specified; whereas with user subroutine
VUINTER the scale factor is ignored.
Output
Most of the standard output variables that are normally available in an
analysis involving contact are available with this capability.
Output for UINTER
The variables COPEN and CSLIP represent the relative positions normal and tangential to the
interface, respectively. The surface-based thermal interaction variable, SFDR, contains the heat flux due to the total energy dissipated due
to friction, and not some fraction of it. This is unlike using the built-in
capability in
Abaqus/Standard,
where SFDR may contain the heat flux due to only a fraction of the total
frictional dissipation, depending on the specified fraction of the dissipated
energy that is converted into heat. In addition, the surface-based thermal
interaction variable WEIGHT, which represents the weighting factor for heat flux (generated
by frictional sliding) distribution between the surfaces, is not available with
this capability.
Additional user-defined output variables can be defined for
UINTER by using the solution-dependent state variables (SDV).
Output for VUINTER and VUINTERACTION
All contact output variables in
Abaqus/Explicit will
be available except output for spot welds (BONDSTAT and BONDLOAD).
The following user subroutine variables will contribute to the associated
total energy variables: the variable sed will
contribute to the energy output variable ALLSE; sfd will contribute to ALLFD; scd will contribute to ALLCD; spd will contribute to ALLPD; and svd will contribute to ALLVD.
If SFDR is requested, sfd,
scd, spd, and
svd will also be used to calculate the heat
generated at the interface (for output purposes only; the generated heat will
not be applied to the model). The default values of the fraction of mechanical
energy converted into heat and the weighting factor for the distribution of
heat between the two surfaces (1.0 and 0.5, respectively) are used.
User-defined, solution-dependent state variables associated with the user
subroutine cannot be output to the output database (.odb)
file or results (.fil) file.
|