김경종
224 lines
13 KiB
Markdown
224 lines
13 KiB
Markdown
<!-- source-page: 1431 -->
|
|
|
|
# 18. Extending Abaqus Analysis Functionality
|
|
|
|
User subroutines and utilities
|
|
|
|
<!-- source-page: 1432 -->
|
|
|
|
<!-- source-page: 1433 -->
|
|
|
|
# 18.1 User subroutines and utilities
|
|
|
|
• “User subroutines: overview,” Section 18.1.1
|
|
• “Available user subroutines,” Section 18.1.2
|
|
• “Available utility routines,” Section 18.1.3
|
|
|
|
<!-- source-page: 1434 -->
|
|
|
|
<!-- source-page: 1435 -->
|
|
|
|
# 18.1.1 USER SUBROUTINES: OVERVIEW
|
|
|
|
# References
|
|
|
|
• “Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD execution,” Section 3.2.2
|
|
• Abaqus User Subroutines Reference Guide
|
|
|
|
# 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 written as C, C++, or 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 9.1.1);
|
|
• cannot be called one from another; and
|
|
• can in some cases call utility routines that are also available in Abaqus (see “Available utility routines,” Section 18.1.3).
|
|
|
|
# Including user subroutines in a model
|
|
|
|
You can include one or more user subroutines in a model by specifying the name of a C, C++, or Fortran source or precompiled object file that contains the subroutines. Details are provided in “Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD execution,” 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 and exchanging information with other software
|
|
|
|
In Abaqus it is sometimes desirable to set up the runtime environment and manage interactions with external data files or parallel processes 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 in Abaqus/Standard and VEXTERNALDB in Abaqus/Explicit. This user interface can potentially be used to exchange data with another code, allowing for “stagger” between Abaqus and another code.
|
|
|
|
<!-- source-page: 1436 -->
|
|
|
|
User subroutines should be written with great care. To ensure their successful implementation, the rules and guidelines below should be followed. For a detailed discussion of the individual subroutines, including coding interfaces and requirements, refer to the Abaqus User Subroutines Reference Guide.
|
|
|
|
# Required INCLUDEs
|
|
|
|
Every user subroutine written in Fortran must include one of the following statements as the first statement after the argument list:
|
|
|
|
• Abaqus/Standard:
|
|
include 'aba\_param.inc'
|
|
• Abaqus/Explicit:
|
|
include 'vaba\_param.inc'
|
|
|
|
If variables are exchanged between the main user subroutine and subsequent subroutines, you should specify the above include statement in all the subroutines to preserve precision.
|
|
|
|
Every C and C++, user subroutine must include the statement
|
|
|
|
#include <aba\_for\_c.h>
|
|
|
|
This file contains macros for the Fortran-to-C interface interoperability.
|
|
|
|
The files aba\_param.inc, vaba\_param.inc, and aba\_for\_c.h 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\_param.inc or vaba\_param.inc 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.
|
|
|
|
User subroutines written in C or C++ will be called from Fortran; therefore, they must conform to the Fortran calling conventions: the name of a C or C++ subroutine must be wrapped in a FOR\_NAME macro; for example,
|
|
|
|
extern “C“ void FOR\_NAME(film)˙˙˙() {˙˙˙ }
|
|
|
|
and the arguments must be passed by reference.
|
|
|
|
<!-- source-page: 1437 -->
|
|
|
|
# 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.” Redefining “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.
|
|
|
|
# Memory allocation considerations
|
|
|
|
Your user subroutine will share memory resources with Abaqus. When you need to use large arrays or other large data structures, you should allocate their memory dynamically, so that memory is allocated from the heap and not the stack. Failure to dynamically allocate large arrays may result in stack overflow errors and an abort of your Abaqus analysis. For an example of dynamic allocation using native Fortran allocatable arrays, refer to “Creation of a data file to facilitate the postprocessing of elbow element results: FELBOW,” Section 15.1.6 of the Abaqus Example Problems Guide. Abaqus also provides another, more convenient way for users to allocate their own storage (see “Allocatable arrays,” Section 2.1.23 of the Abaqus User Subroutines Reference Guide).
|
|
|
|
# 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 log (.log) 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.
|
|
|
|
Environment variable ABA\_PARALLEL\_DEBUG can be set to turn on verbosity, to display compilation and linking commands, and to enable debugging of user subroutines.
|
|
|
|
# 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
|
|
|
|
<!-- source-page: 1438 -->
|
|
|
|
associated with the analysis are closed properly (“Terminating an analysis,” Section 2.1.15 of the Abaqus User Subroutines Reference Guide).
|
|
|
|
# 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.10.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 2.1.5 of the Abaqus User Subroutines Reference Guide). 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.
|
|
|
|
<!-- source-page: 1439 -->
|
|
|
|
# Defining and updating
|
|
|
|
Any number of solution-dependent state variables can be used in the following user subroutines:
|
|
|
|
• CREEP
|
|
• FRIC
|
|
• HETVAL
|
|
• UANISOHYPER\_INV
|
|
• UANISOHYPER\_STRAIN
|
|
• UEL
|
|
• UEXPAN
|
|
• UGENS
|
|
• UHARD
|
|
• UHYPER
|
|
• UINTER
|
|
• UMAT
|
|
• UMATHT
|
|
• UMULLINS
|
|
• USDFLD
|
|
• UTRS
|
|
• VFABRIC
|
|
• VFRIC
|
|
• VFRICTION
|
|
• VUANISOHYPER\_INV
|
|
• VUANISOHYPER\_STRAIN
|
|
• VUFLUIDEXCH
|
|
• VUHARD
|
|
• VUINTER
|
|
• VUINTERACTION
|
|
• VUMAT
|
|
• VUMULLINS
|
|
• VUSDFLD
|
|
• VUTRS
|
|
|
|
<!-- source-page: 1440 -->
|
|
|
|
• VUVISCOSITY
|
|
• VWAVE
|
|
|
|
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 34.6.1.
|
|
|
|
Solution-dependent state variables used in VFRIC, VUINTER, VFRICTION, and VUINTERACTION 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:
|
|
|
|
For 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
|
|
|
|
For subroutine VFRICTION:
|
|
|
|
\*FRICTION, USER=FRICTION, DEPVAR=number of variables
|
|
|
|
For subroutine VUFLUIDEXCH:
|
|
|
|
\*FLUID EXCHANGE PROPERTY, TYPE=USER,DEPVAR=number of variables
|