-
ABAQUS User subroutines
Overview
User subroutines:
?
?
?
?
?
?
are
provided
to
increase
the
functionality
of
several
ABAQUS
capabilities
for which the
usual data input methods alone may be too
restrictive;
provide an extremely
powerful and flexible tool for analysis;
are
typically
written
as
FORTRAN
code
and
must
be
included
in
a
model
when
you execute the
analysis, as discussed below;
must
be
included
and,
if
desired,
can
be
revised
in
a
restarted
run,
since
they are not saved to
the restart files (see
“
Restarting an
analysis,
”
Section
7.1.1
);
cannot be called one
from another; and
can
in
some
cases
call
utility
routines
that
are
also
available
in
ABAQUS
(see
“
Utility routines:
overview,
”
Section
26.1.1
).
Including user
subroutines in a model
You
can include one or more user subroutines in a
model by specifying the name
of a
FORTRAN source or object file that contains the
subroutines. Details are
provided in
“
Execution procedure for
ABAQUS/Standard and ABAQUS/Explicit,
”
Section 3.2.2
.
Input File Usage:
Enter the following input on the
command line:
abaqus
job
=
job-
name
user
={
source-
file
|
object-
file
}
ABAQUS/CAE Usage:
Job module: job editor:
General
:
User
subroutine file
Managing
external databases in ABAQUS/Standard and
exchanging
information with other
software
In ABAQUS/Standard
it
is sometimes
desirable to
set up
the FORTRAN environment
and manage interactions with external
data files that are used in conjunction
with user subroutines. For example,
there may be history-dependent quantities
to be computed externally, once per
increment, for use during the analysis; or
output quantities that are accumulated
over multiple elements in COMMON block
variables within user subroutines may
need to be written to external files at
the end of a converged increment for
postprocessing. Such operations can be
performed with user subroutine
UEXTERNALDB
(
“
UEXTERNALDB,
”
Section 25.2.21
).
This
user
interface
can
potentially
be
used
to
exchange
data
with
another
code,
allowing for “stagger”
between ABAQUS/Standard and another
code.
Writing a user
subroutine
User subroutines
should be written with great care. To ensure their
successful
implementation, the rules
and guidelines below should be followed.
Required INCLUDE statement
Every ABAQUS/Standard user subroutine
must include the statement
include
'aba_'
as the first statement after the
argument list.
Every ABAQUS/Explicit
user subroutine must include the statement
include 'vaba_'
as the first
statement after the argument list.
If
variables are exchanged between the main user
subroutine and subsequent
subroutines,
the user should specify the above include
statement in all the
subroutines to
preserve precision.
The files aba_ and
vaba_ are installed on the system by the
ABAQUS installation procedure and
contain important installation parameters.
These statements tell the ABAQUS
execution procedure, which
compiles and
links
the user subroutine with the rest
of ABAQUS, to include the aba_ or
vaba_
file
automatically.
It
is
not
necessary
to
find
the
file
and
copy
it to any particular
directory; ABAQUS will know where to find it.
Naming convention
If user
subroutines call other subroutines or use COMMON
blocks to pass
information, such
subroutines or COMMON blocks should begin with the
letter K
since this letter is never
used to start the name of any subroutine or COMMON
block in ABAQUS.
Redefining
variables
User
subroutines
must
perform
their
intended
function
without
overwriting
other
parts of ABAQUS. In particular, you
should redefine only those variables
identified in this chapter as
“variables to be defined.” R
edefining
“variables passed in for information”
will have unpredictable effects.
Compilation and linking problems
If problems are encountered during
compilation or linking of the subroutine,
make sure that the ABAQUS environment
file (the default location for this file
is
the
site
subdirectory
of
the
ABAQUS
installation)
contains
the
correct
compile
and link commands as
specified in the
ABAQUS Installation
and Licensing Guide
.
These
commands should have been set up by the ABAQUS
site manager during
installation. The
number and type of arguments must correspond to
what is
specified in the documentation.
Mismatches in type or number of arguments may
lead to platform-dependent linking or
runtime errors.
Testing and debugging
When developing user subroutines, test
them thoroughly on smaller examples in
which the user subroutine is the only
complicated aspect of the model before
attempting to use them in production
analysis work.
If needed, debug output
can be written to the ABAQUS/Standard message
(.msg)
file using FORTRAN unit 7 or to
the ABAQUS/Standard data (.dat) file or the
ABAQUS/Explicit
status
(.sta)
file
using
FORTRAN
unit 6;
these
units
should
not
be
opened by your routines since they are already
opened by ABAQUS.
FORTRAN units 15
through 18 or units greater than 100 can be used
to read or
write other user-specified
information. The use of other FORTRAN units may
interfere
with
ABAQUS
file
operations;
see
“
FORTRAN
unit
numbers
used
by
ABAQUS,
”
Section
3.7.1
. You must open these FORTRAN
units; and because of the use of
scratch directories, the full pathname
for the file must be used in the OPEN
statement.
Terminating an
analysis
Utility
routine
XIT
(ABAQUS/Standard)
or
XPLB_EXIT
(ABAQUS/Explicit)
should
be
used
instead
of
STOP
when
terminating
an
analysis
from
within
a
user
subroutine.
This
will
ensure
that
all
files
associated
with
the
analysis
are
closed
properly
(
“
Terminating an
analysis,
”
Section
26.2.12
).
(
CALL
XIT
or
CALL XPLB_EXIT
)
Models defined in terms of an assembly
of part instances
An ABAQUS
model can be defined in terms of an assembly of
part instances (see
“
Defining an
assembly,
”
Section
2.9.1
).
Reference coordinate
system
Although a local coordinate
system can be defined for each part instance, all
variables (such as current coordinates)
are passed to a user subroutine in the
global coordinate system, not in a
part-local coordinate system. The only
exception to this rule is when the user
subroutine interface specifically
indicates that a variable is in a user-
defined local coordinate system
(
“
Orientations,
”
Section 2.2.5
, or
“
Transformed coordinate
systems,
”
Section
2.1.5
). The local coordinate
system originally may have been defined relative
to
a
part
coordinate
system,
but
it
was
transformed
according
to
the
positioning
data given for
the part instance. As a result, a new local
coordinate system
was created relative
to the assembly (global) coordinate system. This
new
coordinate system definition is the
one used for local orientations in user
subroutines.
Node and
element numbers
The node and element
numbers passed to a user subroutine are
internal numbers
generated by ABAQUS. These numbers are
global in nature; all internal node and
element numbers are unique. If the
original number and the part instance name
are required, call the utility
subroutine
GETPARTINFO
(ABAQUS/Standard) or
VGETPARTINFO
(ABAQUS/Explicit)
from
within
your
user
subroutine
(see
“
Obtaining
part
information,
”
Section
26.2.4
).
The
expense
of
calling
these
routines
is
not
trivial, so minimal use of them is
recommended.
Another utility
subroutine,
GETINTERNAL
(ABAQUS/Standard) or
VGETINTERNAL
(ABAQUS/Explicit), can be used to
retrieve the internal node or element number
corresponding to a given part instance
name and local number.
Set and surface
names
Set and surface names passed to
user subroutines are always prefixed by the
assembly and part instance names,
separated by underscores. For example, a
surface named surf1 belonging to part
instance Part1-1 in assembly Assembly1
will be passed to a user subroutine as
Assembly1_Part1-1_surf1
Solution-dependent state variables
Solution-dependent
state
variables
are
values
that
can
be
defined
to
evolve
with
the solution of an analysis.
Defining and updating
Any
number of solution-dependent state variables can
be used in the following
user
subroutines:
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
“
CREEP,
”
Section 25.2.1
“
FRIC,
”
Section 25.2.8
“
HETVAL,
”
Section 25.2.12
“
UEL,
”
Section 25.2.19
“
UEXPAN,
”
Section 25.2.20
“
UGENS,
”
Section 25.2.24
“
UHARD,
”
Section 25.2.25
“
UHYPER,
”
Section 25.2.27
“
UINTER,
”
Section 25.2.28
“
UMAT,
”
Section 25.2.30
“
UMATHT,
”
Section 25.2.31
“
UMULLINS,
”
Section 25.2.34
“
USDFLD,
”
Section 25.2.39
“
UTRS,
”
Section 25.2.42
“
VFRIC,
”
Section 25.3.2
“
VUINTER,
”
Section 25.3.3
“
VUMAT,
”
Section 25.3.4
The
state
variables
can
be
defined
as
a
function
of
any
other
variables
appearing
in these
subroutines and can be updated accordingly.
Solution-dependent state
variables
should
not
be
confused
with
field
variables,
which
may
also
be
needed
in the
constitutive routines and can vary with time;
field variables are
discussed in detail
in
“
Predefined
fields,
”
Section
19.6.1
.
Solution-dependent
state
variables
used
in
VFRIC
and
VUINTER
are
defined
as
state
variables at slave nodes and are
updated with other contact variables.
Allocating space
You must
allocate space for each of the solution-dependent
state variables at
every applicable
integration point or contact slave node.
Separate
user
subroutine
groups
have
been
identified
that
differ
in
the
way
the
number of
solution-dependent state variables is defined.
These groups are
described
below.
Solution-dependent
state
variables
can
be
shared
by
subroutines
within the same group; they cannot be
shared between subroutines belonging to
different groups.
Input File
Usage:
F
or most
subroutines the
number of
such variables
required at the points
or nodes is entered as the
only
value
on
the
data
line
of
the
*DEPVAR
option,
which should be
included as part of the material
definition for every material in which
solution-dependent state variables are
to be
considered:
*DEPVAR
For
subroutines that do not use the material
behavior defined with the
*MATERIAL
option, the
*DEPVAR
option is not used.
For subroutine UEL:
*USER
ELEMENT
, VARIABLES=
number of
variables
For subroutine
UGENS:
*SHELL
GENERAL
SECTION
,
USER,
VARIABLES=
number
of
variables
For subroutines FRIC and VFRIC:
*FRICTION
, USER,
DEPVAR=
number of variables
For subroutines UINTER and VUINTER:
*SURFACE INTERACTION
, USER,
DEPVAR=
number of
variables
ABAQUS/CAE Usage:
F
or most subroutines the
number of such variables required
at
the points or nodes is entered as part of the
material
definition for every material
in which solution-dependent
state
variables are to be considered:
Property module: material editor:
General
Depvar
:
Number
of
solution-dependent state variables
Defining initial values
You can define the initial values of
solution-dependent state variable fields
directly or in ABAQUS/Standard through
a user subroutine. The initial values
of solution-dependent state variables
for contact in ABAQUS/Explicit are
assigned as zero internally.
-
-
-
-
-
-
-
-
-
上一篇:全部 外贸知识 问答题 (力荐!)
下一篇:第十九课 现在习惯了