ABAQUS Scripting for Engineering Analysis Projects

A Consultants Perspective
David C. Winkler and Zhouhua Li
ABAQUS Solutions Northeast, LLC., 300 Centerville Road, Warwick, RI 02886-0201, U.S.A.
The realities of engineering problem solving, especially when working as a finite element analyst to
companies developing products in competitive environments, require the engineer to deploy all tools at his
disposal in order to optimize productivity. Scripting is one of the best tools available because it enables
rapid development of utilities, customizations, and applications that can automate repetitive tasks, reduce
modeling errors, and enhance the interpretation of results. ABAQUS Solutions Northeast, LLC (ASN) has
come to rely on the Python scripting language, and the Python based APIs in ABAQUS, in it consulting
operations. Some examples of special purpose scripts that were used to automate modeling tasks, augment
the functionality of the ABAQUS interactive products, and do calculations which are outside the scope of
general purpose solver or post-processor, are discussed. ABAQUS scripts have been deployed at ASN to:
map meshes to change model topology, post process to determine peak result values and their locations,
transform results to arbitrary coordinate systems, add graphical user interface components to
ABAQUS/CAE and ABAQUS/Viewer, automate the generation of patterned features, generate solid
models from 2D drawings, and so on.
By relying on the Object Oriented Programming (OOP) techniques often associated with the Python
language and the emerging ABAQUS database model, an analyst, even one without an extensive computer
programming background, can improve his productivity and work product quality.

1. Introduction
Initially developed in 1990, Python is an interpreted, object oriented scripting language that is powerful, yet
simple enough for user-level scripting with a small amount of training. It offers an extensive collection of
libraries to help the user to access almost any kind of data. While it is not revolutionary in what it offers, it
seems to effectively combine many good ideas from other well established languages.
With the introduction of v5.8 in 1998, Python was embedded within the ABAQUS commercial finite
element software at different levels. At the time, Python had not yet experienced wide acceptance. Even
now, our casual exposure to related internet chat leaves us with the impression that some industry decision
makers continue to argue this point. In light of the relative age of the language, embedding Python in a
commercial product such as ABAQUS was nothing short of radical. We are convinced that the decision
will have a positive and substantial effect on the long term direction of the code.

Correspondence to D. C. Winkler, E-mail: winkler@abaqus-sn.com

2002 ABAQUS Users Conference

The Python based application programming interface (API) and extensive object model that are now part
of ABAQUS have dramatically changed the way that users can interact with the code. At ABAQUS
Solutions Northeast, LLC. (ASN), we have come to embrace Python as a language for general purpose use.
In our engineering consulting business, we rely on the scripting API to respond to our customers needs for
cost effective physics based modeling. To date, we have been motivated to use scripting for the following
reasons:

To automate repetitive tasks (including model building, job submission, job monitoring, post
processing, and prescribing default parameters for ABAQUS jobs)
To document sessions and jobs (using the ABAQUS journal files and our own scripts)
To extend functionality
To enhance the standard interfaces (graphical and non-graphical)

When creating new models, we regularly work with the journal files in order to create reliable,
parameterized, easy to read text files that serve as a basis for archiving data and building new variations of
the same model. These files are generally much easier to read than the unedited journal files and tend to be
less prone to corruption than the binary model database file (MDB). We find that there are times when it is
easier to build models using the graphical user interface (GUI), and there are times when it is easier to build
models by creating and running/importing scripts.
When we require special functionality that is not supported by the current version of ABAQUS, we use
scripting to add the functionality. When we catch ourselves using custom functionality more often, we take
the time to package code for easier accessibility and reuse. If routines have broad application we try to
make them available to our entire engineering staff.
We typically access our homegrown custom functionality from the command line and tend to make much
use of ASCII files for defining and archiving user defined parameters. Recently, we have begun to collect
some of our extensions in a custom module of ABAQUS/CAE. Doing this requires a bit more effort up
front, but ultimately enhances ease-of-use.
What follows, is a rather light discussion about the type of tasks that our company currently performs with
the Python based ABAQUS scripting interface. Our intent is not to provide a detailed explanation about
the workings of individual scripts. Instead, we simply expose the reader to some of our own experiences at
a high level. We hope that through a discussion of a few examples, we can encourage some users to
consider employing the ABAQUS scripting interface in new ways.

2. Working with the ABAQUS object model

2.1

Object model interrogation

A common source of frustration for new users of the ABAQUS scripting interface (ASI) is that the object
model cannot be easily viewed in its entirety. Users with programming experience recognize this. Users
without programming experience initially feel that ABAQUS scripting is too difficult to use. The
frustration is understandable because HKS has extended Python with hundreds of new object types.

Also referred to as the ABAQUS Scripting Interface (ASI).

2002 ABAQUS Users Conference

Without being able to view a single figure that defines a large collection of the object names and
inheritance, it can be difficult for the new user to establish the bearings necessary to create a new script. It
should be noted that ABAQUS documentation is available on-line for all of the ABAQUS objects. There
are figures describing some of the branches of the object model. Unfortunately, this is not always enough
to readily provide a user with the big picture.
This limitation is easily overcome by using a few common techniques that are made available in Python.
For example, we make regular use of the following Python commands:
object.__members__- returns a list of data names that is encapsulated by the object.
object.__methods__- returns the names of functions that are available to manipulate object data.
modulename.__file__ - returns the name of the file that the module was loaded from.
modulename.__dict__.keys() returns a list of the modules namespaces.
name.__doc__- returns the documentation string for a function, method, module, or class.
type(object) - returns the type object of an object.
globals() - returns a dictionary representing the present global symbol table.
dir(),locals() - returns a dictionary representing the present local symbol table.
dir(object) - returns a list of valid attributes of an object.
repr(object) - returns the formal string representation of an object.

At ASN, our understanding and effective usage of the object model has benefited from writing simple
scripts that do nothing more than interrogate the object model at different levels. This helps us in our
consulting work as well as our daily technical support of customer problems. For example, in one script
that we have written called odbq.py, data is read from an output database file (ODB). After the read,
summary information is returned in textual form. The user has the choice of returning information to
standard output or to a filename of his/her choosing. In the current version of the script, the type of
information that is returned, is specified by the user. For example, the following text is written when
specifying an odb type of query .
The command:
abq621 python odbq.py filename results_centroid.odb query odb

The return:
THESE ARE THE RESULTS OF A ODB QUERY FOR 'odb' INFORMATION
------------------------------------------------------------------------------Filename to read = results_centroid.odb
The 'odb' object is a <type 'Odb'>
analysisTitle =
G= 150, Fillet Type= c, THK = 0.5, L = 2, FET = 0.035, FEL = 0.08,
FR = 0.1
description =
Test ddb file
jobData =
({'name': 'C:/winkler/test2/example12_object_model_query_v61/results_centroid.odb',
'analysisCode': ABAQUS_STANDARD,
'version': 'ABAQUS/Standard 6.1-1',
'creationTime': 'Thu Mar 29 16:53:45 Eastern Standard Time 2001',
'modificationTime': 'Thu Mar 29 16:54:15 Eastern Standard Time 2001',
'machineName': '', 'precision': SINGLE_PRECISION})
name =
C:/winkler/test2/example12_object_model_query_v61/results_centroid.odb
part =
{'PART-1': 'DiscretePart object'}
path =
C:/winkler/test2/example12_object_model_query_v61/results_centroid.odb

2002 ABAQUS Users Conference

rootAssembly =
({'name': 'Assembly-1',
'instance': 'Repository object',
'nodeSet': 'Repository object',
'elementSet': 'Repository object',
'surface': 'Repository object'})
sectionCategory =
{'solid < G150 >': 'SectionCategory object'}
sectorDefinition =
None
step =
{'Step
1': 'OdbStep object',
'Step
2': 'OdbStep object',
'Step
3': 'OdbStep object',
'Step
4': 'OdbStep object',
'Step
5': 'OdbStep object',
'Step
6': 'OdbStep object',
'Step
7': 'OdbStep object',
'Step
8': 'OdbStep object',
'Step
9': 'OdbStep object'}
userData =
({'xyData': 'userXYDataDictIntObj object'})
type
validInvariants
value

This command returns some high level information about the ODB. For example, here we were able to
determine that the ODB was created using ABAQUS/Standard version 6.1, during March 2001. There are
9 steps, 1 part, and 1 section definition in the ODB. It is interesting to note that this script informs us that
the ODB file is a Python type that is called <type 'Odb'>. This is one of the many types that HKS has
added to the standard distribution of Python. The ODB object is one of the roots of the ABAQUS object
model.
The same script is used to extract other information from the same ODB by using different command line
arguments. The following command is used to perform a frame type of query:
The command:
abq621 python odbq.py filename results_centroid.odb query frame

The return:
THESE ARE THE RESULTS OF A ODB QUERY FOR 'frame' INFORMATION
------------------------------------------------------------------------------Filename to read = results_centroid.odb
Step number = LAST
Frame number = LAST
The 'odb.step[stepname].frame' object is a <type 'Sequence'> of <type 'OdbFrame'>
Frame #2
------------------------------------------------------------------------------associatedFrame = None
cyclicModeNumber = None
description = Increment
1: Step Time =
1.000
domain = TIME
fieldOutput = ['S', 'PENER', 'VENER', 'RF', 'JENER', 'LE']
= ['NE', 'RM3', 'SENER', 'CENER', 'EENER', 'U']
= ['UR3']
frameId = 1
frameValue = 1.0
frequency = None
isImaginary = NO
mode = None

The information that is returned provides us with some details about the last frame in the last step. In both
cases, LAST was defined as a default argument in the function and need not be specified at the command

2002 ABAQUS Users Conference

line. Here we learn that the frame object is a sequence of <type 'OdbFrame'> objects. With this
frame query, we are now getting a little deeper into the object model. We learn that frame is owned by
step which is owned by odb. We also get a list of all the output variables that are available in the
particular frame.
The user is generally free to access information at any level and return the information in many different
ways. In this script, we use text with indentation to designate the hierarchy of the information (i.e. the
branching within the object model). As a final example, we use the same command to perform a
fieldoutput type of query.
The command:
abq621 python odbq.py filename results_centroid.odb query fieldoutput

The return:
THESE ARE THE RESULTS OF A ODB QUERY FOR 'fieldOutput' INFORMATION
------------------------------------------------------------------------------Filename to read = results_centroid.odb
Element set to search = ALL
Variable(s) to get = S
Step Number = LAST
Frame Number = LAST
Item Number = 1
The 'odb.step[name].frame[i].fieldOutput[name]' object
is a <type 'Repository'> of <type 'FieldOutput'>
Field output = Stress components
------------------------------------------------------------------------------componentLabels = ('S11', 'S22', 'S33', 'S12')
description = Stress components
location = <type 'Sequence'> of <type 'FieldLocation'>
...there are 2 items. Below is info on the item #1
position = INTEGRATION_POINT
sectionPoint = <type 'tuple'>
...there are 0 items.
name = S
type = TENSOR_2D_PLANAR
validInvariants =(MISES, MAX_INPLANE_PRINCIPAL, MIN_INPLANE_PRINCIPAL)
(OUTOFPLANE_PRINCIPAL, MAX_PRINCIPAL, MID_PRINCIPAL)
(MIN_PRINCIPAL, TRESCA, PRESS, INV3)
value = <type 'Sequence'> of <type 'FieldValue'>
...there are 2840 items. Below is info on item #1
conjugateData = None
data = (0.0150647452101, -0.0100335273892, 0.00251366337761, 0.00536285759881)
elementLabel = 1
face = None
instance =
element = Sequence object
elementSet = Repository object
embeddedSpace = THREE_D
name = PART-1-1
node = Sequence object
nodeSet = Repository object
surface = Repository object
type = DEFORMABLE_BODY
integrationPoint = 1
inv3 = 0.00148339697625
magnitude = None
maxInPlanePrincipal = 0.0161626264453
maxPrincipal = 0.0161626264453
midPrincipal = 0.00251366337761
minInPlanePrincipal = -0.011131407693
minPrincipal = -0.011131407693
mises = 0.0236373264343
nodeLabel = None
outOfPlanePrincipal = 0.00251366337761
position = INTEGRATION_POINT

2002 ABAQUS Users Conference

press = -0.00251496070996
sectionPoint = None
tresca = 0.0272940341383
type = TENSOR_2D_PLANAR
THESE ARE THE RESULTS OF A ODB QUERY FOR 'fieldOutput' INFORMATION

This type of script readily provides us with a map or tree of whatever level of detail we require of the object
model. Of course, the same basic Python commands that are issued in our script may also be used at the
command line interface (CLI) of ABAQUS/CAE and /Viewer. In fact, when we are creating new scripts at
ASN, we find that we are constantly switching between different namespaces and processes. We issue
commands at the CLI and interactive windows of the interactive development environments (IDEs are
explained in next section). We run scripts and import files from /CAE and the IDEs. In almost all cases,
most of our original code is extracted from the /CAE journaling files (.jnl, .rpy, and .rec).
2.2

Using 3rd party integrated development environments (IDEs)

Third party IDEs are available to provide features for effective Python programming. Multi-document
editing allows the user to work on multiple documents simultaneously and archive multiple files as a single
project. Syntax-checking and coloring provides instant feedback that makes it easier to quickly write
proper code. Various editing features are available for commenting, indenting/outdenting, block selection,
etc. Code-folding lets the user work quickly and efficiently with large sections of code. Auto completion
lets the user write code faster and shorten the learning curve by providing features that guide you as you
work. Call-tips help you fill in the parameters or arguments for a method by automatically presenting you
with a list of valid parameters or arguments for a given function or method as you begin to type in the
name. Similarly, call-tips provide the user with lexical scoping information: a list of names that are
available within the specified namespace.
Unfortunately, no IDE is delivered with ABAQUS. At ASN, we make use of IDEs that are available from
3rd parties for a small to zero fee. We primarily use Pythonwin and Komodo**. We also use text editors
that provide syntax coloring. TextPad on Windows platforms and nedit on UNIX do a fine job. Our choice
of which tool to use is determined by the task we are trying to accomplish. When working with many files
at the same time, we like to take advantage of Komodos project feature. When running scripts outside of
ABAQUS, we like to use the ease-of-use and fine interactive window found in Pythonwin. When making
color coded printed output of our scripts, we like to use the text editors. The editors perform automatic line
wrapping which lets us cheat the scripting formatting rules by using very large line lengths.

3. Manipulating text for input and output

Most finite element analysts maintain a few routines that are used for processing text (string type data).
These collections typically include some FORTRAN code that has been around for a while. It has been our
experience that Python and the ASI provide very effective utilities for working with ABAQUS related

Pythonwin is part of the win32all distribution that is developed by Mark Hammond

(http://starship.python.net/crew/mhammond/)
**
Komodo is developed by the Active State Corporation (http://www.activestate.com)

2002 ABAQUS Users Conference

strings. This is important to us because string manipulation is a requirement of most of our consulting jobs.
For example, it is common for us to receive ASCII files that contain tables of customer data that define
material properties and or time histories. This information must be quickly converted into a format that is
properly recognized by ABAQUS input files. Minor challenges are that the customer format is always
different and the number of data line columns is dependent on the ABAQUS option that is being used. It is
nice to have a scripting language with a comprehensive set of string methods and easy to read syntax.
To get an idea of how easy these scripts can be to create, below is an example of some code that is used to
read an abaqus.rpt file and generate another file that is consistent with ABAQUS datalines needed for
the *AMPLITUDE option. In ABAQUS/CAE the user can produce a tabular data report of either X-Y data
objects, field output results, or probe values and write the report to an ASCII file. This feature (called
Report) offers a number of user controls over data format. In order to realize unsupported formats, the user
must write a script like this one to read data directly from the ODB, or to manipulate the ASCII data from
Report.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
def stringChop(string,tol):
number = float(string)
if abs(number) < tol:
number = 0.
return str(number)
stringList=string.split(fileRead('abaqus.rpt'))
slot=stringList.index('Temp-1')
stringList=stringList[slot+1:]
fileName='wink.txt'
tol=.00000001
fileWrite(fileName,'*AMPLITUDE,NAME=amp1',0)
startPoints=range(0,(len(stringList)/8)*8,8)
sep=', '
for i in startPoints:
dataList=[stringList[i+0],
sep, stringChop(stringList[i+1],tol),
sep, stringList[i+2], sep, stringChop(stringList[i+3],tol),
sep, stringList[i+4], sep, stringChop(stringList[i+5],tol),
sep, stringList[i+6], sep, stringChop(stringList[i+7],tol), sep ]
fileWrite(fileName,dataList,1)
shortStringList=stringList[-(len(stringList)-(startPoints[-1]+8)):]
if shortStringList:
dataList=[]
for item in shortStringList:
dataList.append(item)
dataList.append(sep)
fileWrite(fileName,dataList[:-1],1)

As another string manipulation example, we have included a portion of some code below that we use to
convert end-of-line characters when transporting files between Windows and Unix platforms. It is nice to
have simple code available to perform such tasks.
def toDos(fileName):
i = open(fileName, 'r')
t = i.read()
i.close()
s = string.join(string.split(t, "\012"), "\015\012")
o = open(fileName, 'w')
o.write(s)
o.close()
print 'finished'
def toUnix(fileName):
i = open(fileName, 'r')
t = i.read()
i.close()

2002 ABAQUS Users Conference

s = string.join(string.split(t, "\015\012"), "\012")

o = open(fileName, 'w')
o.write(s)
o.close()
print 'finished'

4. File system maintenance

Python is well suited for performing system administration tasks. As it relates to ABAQUS, we have
occasionally written code to perform customized monitoring of disk usage for ASN users across all the
systems on our network. We have also developed code to clean-up (delete) ABAQUS related files. As an
example, below is the return information from two particular disk usage queries.
The command for query #1:
asn_os.py ufunc du sysname troi

The return for query #1:

***************************************************************************
Disk usage information for the following posix system:
...machine name = troi
...operating system = HP-UX B.11.00
Total troi disk usage for kamaraj = 2.731 gigabytes
Total troi disk usage for koplik = 8.134 gigabytes
Total troi disk usage for li = 16.672 gigabytes
Total troi disk usage for rotelli = 0.003 gigabytes
Total troi disk usage for winkler = 10.052 gigabytes
Total troi disk usage for woyak = 3.967 gigabytes
***************************************************************************
The disk hog of the week is ***---> li <---***
***************************************************************************

The command for query #2:

asn_os.py ufunc du sysname troi username li filefilter yes

The return for query #2:

***************************************************************************
Disk usage information for the following posix system:
...machine name = troi
...operating system = HP-UX B.11.00
...user = li
.com --->
.dat --->
.fil --->
.log --->
.mdl --->
.msg --->
.prt --->
.res --->
.sta --->
.stt --->
.inp --->
.odb --->
core --->
atot --->
else --->

0.000172106
0.15652743
2.535902008
3.6691e-05
0.079015936
0.0097792
0.041610464
1.037470367
6.5813e-05
1.41821952
0.256699045
4.623757008
0.153131256
10.312
6.306

Total troi disk usage for li = 16.672 gigabytes

***************************************************************************

2002 ABAQUS Users Conference

5. Top-down model building

ABAQUS/CAE provides an environment that is based on a top-down approach. In top-down geometric
modelling, higher dimensional entities are directly created while their lower dimensional building blocks
are automatically created. For example, in ABAQUS/CAE, a volume may be directly created by extruding
a sketch without having to specify every point, line and surface required to build the entire volume.
Extending the concept to finite element pre-processing, a mesh may be directly created without specifying
each nodal coordinate and element connectivity. Similarly, boundary conditions may be directly applied to
geometry and automatically associated with a mesh. Top-down models tend to be feature based and
support useful parent-child relationships that parallel the concepts found in OOP.
Top-down model building scripts are usually straight forward and easy to create because command may be
directly extracted from the /CAE journal files. Parameterization is easy to facilitate, especially when the
topology is unchanging. At ASN, we regularly make use of top-down model building scripts, even when
the task at hand does not specify that any scripting is required.
For example, the IC solder ball grid model shown in Figure 1 was generated using a top-down modelling
script. This type of periodic structure lends itself nicely to the model building features of /CAE and the
programming constructs of a language such as Python. The geometry was supplied by the customer and
automatically imported into /CAE. Multiple instances of the solder ball were created and positioned by
using a Python loop. Repetitious partitioning of the chip frame, and definition of the many contact
interactions, was also automated in a loop. User controls were included to allow for solder ball mesh
refinement as a function of position within the grid.

Figure 1. Example of a IC solder ball grid model built using a top-down script
2002 ABAQUS Users Conference

Much of out scripting work has involved top-down model building. We make use of all of the native
geometry tools and implement our own when we need them. For example, we have written our own
geometric constraint routines. Some of our customers document their engineering designs on two
dimensional drawings in DXF format. Several times, we have had the opportunity to develop scripts that
provide an automated process for building complete, 3D FE models from imported drawings.

6. Bottom-up model building

ABAQUS/CAE provides very few bottom-up modeling features. In bottom-up geometric modeling, higher
dimensional entities are created from lower dimensional entities that have already been directly defined by
the user. For example, a volume may be created by specifying six existing surfaces. Extending the concept
of bottom-up geometric modeling to finite element pre-processing, elements and nodes may be created by
explicitly specifying the nodal connectivity and nodal coordinates respectively. In practice, a lower
dimensional entity usually cannot be deleted if it is related to a higher dimensional entity
Bottom-up modeling techniques are relatively tedious and have largely been replaced in commercial FEA
codes by top-down methods. Even so, at ASN we find that the ability to perform rudimentary bottom-up
tasks can help us complete some jobs with very little effort. To perform bottom-up modelling with /CAE,
we utilize the scripting API.
We have successfully enhanced /CAE to include most of the bottom-up functionality that we need to
perform our consulting work. We continue to build upon our own library of scripting utilities that allows
us to work with the individual primitives that may be otherwise inaccessible from the /CAE graphical user
interface. Typically, this functionality applies to nodes and elements because these are the primitives that
are most difficult to directly control in /CAE. We have developed functions for merging nodes, mapping
nodal coordinates from one coordinate system to another, performing Boolean operations on element and
node sets, automatically inserting spring elements, etc.
In addition to enhancing the /CAE product to include more bottom-up features, we have found that
scripting may be used to provide enhanced support for ABAQUS input file KEYWORDS that may be
missing from the current /CAE interface.
Scripting for bottom-up modeling and for providing enhanced KEYWORD support requires the user to
interface with the keywordBlock object. This is an object that has not realized as much attention as it
deserves. Simply put, the keywordBlock object contains ABAQUS option blocks. An option block is an
ABAQUS/Standard or ABAQUS/Explicit keyword along with the parameters and data lines associated
with the keyword. A block can also be a comment. The keywordBlock object is available in three different
forms: as a single string called the ABAQUS Input File (mdb.model[name].keywordBlock.aifText),
as a list of strings called the Solver Input Editor file (mdb.model[name].keywordBlock.sieText), or
as the actual input file itself (jobname.inp).
In order to effectively interact with the keywordBlock object, it is helpful if the user is familiar with the
Python modules called string and re. String manipulation is almost always required. The next few
subsections address some specific examples of bottom-up modeling scripts that we have developed for our
own use.

10

2002 ABAQUS Users Conference

6.1

Node merging

ABAQUS has a wide array of robust methods for prescribing welded type interactions between disjoint
bodies. Included are the ABAQUS features called tied constraints, tied contact, connector elements, multipoint constraints and equations, and kinematic coupling. In addition to using these types of interactions to
join bodies together, single parts can be defined with different regions, each region comprised of its own
material property and/or section definition. In these cases, meshing in /CAE will automatically merge the
nodes between dissimilar regions within a single part.
These types of modeling features do a nice job handling most of the needs of a typical analyst. Despite
this, there are times when direct merging (or coalescing) of nodes is exactly what we want and need. For
example, the ABAQUS feature called skinning is unsupported in 2D. Node merging provides a convenient
work-around. Similarly, node merging allows the user to weld bodies together as an afterthought (i.e. there
is no need to re-create the two bodies as a single part or define interactions). We acknowledge that because
of the requirement for a matched mesh on both regions, node merging does not provide a general solution
for this type of situation. Regardless of its shortcomings and the availability of alternate approaches, we
view node merging as an important pre-processing tool.
To facilitate this type of bottom-up behavior, we have created functionality that allows the user to merge all
nodes within a prescribed node-set, based on a user prescribed tolerance. We make use of the efficient
Python extensions that are collectively referred to as NumPy. These extensions provide features for
efficiently manipulating large arrays of data. We do this because node merge operations may be required
to be used on large /CAE model databases (MDBs) and the standard Python data structures such as lists and
tuples are too slow and use too much memory for these cases. Figure 2 demonstrates our node merge
utility for two bodies subjected to a uniform side loading. Similar to all of our bottom-up scripting, the
database is modified immediately prior to the job submission. All bottom-up modifications that are made
to the keywordBlock object may be easily deleted prior to making subsequent top-down changes to the
model database and may be easily reapplied again prior to job submission.

uniform pressure load

behavior
prior to
node
merge

behavior
after
node
merge

Figure 2. Simple example using a custom node merge utility

2002 ABAQUS Users Conference

11

6.2

Node generation

Node generation keyword options (*NGEN, *NCOPY, *NFILL, and *NMAP) are available in the
ABAQUS input file for creating nodes and their coordinates according to geometrically simple mappings
that rely on existing *NODE definitions. These options are rudimentary but can sometimes provide a nice
solution to certain geometry building tasks. Perhaps this is why they were included in the early versions of
ABAQUS. While it is not very common, there are times when it is easier for us to generate geometry by
using simple node mapping routines than by using the native geometry features contained in /CAE.
Node generation operations may be replicated in /CAE by using the scripting interface. We have
developed some bottom-up scripts that replicate the functionality of some of the input file keywords. For
example, we have replicated the functionality of *NMAP.
We like the functionality of *NMAP because it seems to parallel the design and analysis procedures that
are used by some of our customers. Even with the proliferation of sophisticated CAD software, some
product designs are created and documented as flat pattern layouts (i.e. two-dimensional drawings). This is
particularly true when the manufacturing process begins with some kind of flat stock of material. In these
cases, the FE analyst must use the flat pattern and a description of the intended coordinate mapping to
generate the final geometry in order to analyze the parts. When we are asked to perform jobs like these, we
use our custom implementation of *NMAP. Figure 3 demonstrates the algorithm in use. The viewport on
the left represents the initial flat geometry immediately prior to mapping. The viewport on the right
represents the geometry after the nodal coordinates have been mapped to a cylindrical coordinate system.
Obviously, the coordinate transformation part of the algorithm would be considered to be fairly generic and
represents the kind of code that we like to reuse whenever possible.

Prior to node
mapping

After node
mapping

Figure 3. Simple example using a custom *NMAP utility

12

2002 ABAQUS Users Conference

6.3

Node/element Boolean operations

Significant improvements continue to made to ABAQUS in the area of overconstraint checking. An

overconstraint is the condition that exists when multiple or inconsistent kinematic constraints have been
applied to a model. We have recently come to find that ABAQUS can gracefully handle several different
types of overconstraint situations. There continue to be situations however, that are not handled
automatically. Many times this creates frustration for the user because the overconstraint can result in an
error, yet it is readily apparent that the overcontraint condition can be eliminated by simply removing a
node from one node or element set. Unfortunately this type of bottom-up task (removing a node or element
from a set) cannot be easily performed in /CAE.
At ASN we have used the scripting interface to provide the user with control over the manipulation of
existing node and element sets. For example, we have introduced a complement function that returns all the
nodes or elements from a large set that are not also in a smaller set. In other words, we provide the user the
ability to remove nodes or elements from an existing set. In our implementation, the user supplies the
names of existing geometry sets and does not need to specify node or element numbers.
Figure 4 demonstrates this bottom-up customization in action. Here we have three T-shaped parts that are
constrained together using ABAQUS tied constraints. When the job is submitted, an error is issued for
ABAQUS/Standard version 6.2-4 for one node that participates in two different *TIE constraint definitions.
The error may be easily avoided by eliminating this node from one surface of one of the tied constraints
without adversely affecting the physics of the problem. We used scripting to perform this task. The user
defines the node to be removed by referencing the associated geometry (i.e. the vertex). The image in the
middle highlights the resulting node-set for the surface definition. The same approach can also be used
with element based surface definitions. With this modification, the job runs to completion.

***ERROR: 1 nodes are missing degree of freedoms. The MPC/Equation/kinematic

coupling constraints can not be formed. The nodes have been
identified in node set ErrNodeMissingDofConstrDef.

uniform pressure load

remove node at
vertex from contact
node set
*TIE used to join 3
different parts

now job runs to

completion

Figure 4. Simple example of a node being removed from a nodeset.

2002 ABAQUS Users Conference

13

6.4

Automatic spring insertion

The definition of ABAQUS spring elements can be performed effectively with the scripting interface. We
have developed scripts for inserting one node and two node spring elements. We mention this example
because the absence of spring elements from the /CAE user interface is conspicuous to most users. It may
not be apparent that scripting provides an effective means for creating individual spring elements and also
for automatically creating many spring elements at once. The latter operation is handy when using soft
springs as an alternative to the ABAQUS feature called *STABILIZE.
6.5

Enhancing /CAE to support all input file KEYWORD blocks

At version 6.2, not all of the ABAQUS input file keyword options have been fully incorporated in the
/CAE graphical user interface. When a user requires access to an unsupported keyword, a common
approach is to manually edit the keywordBlock object using the keyword editor in /CAE. Unfortunately,
not all keyword block edits are supported by the keyword editor dialog. Another approach is to directly
modify the input file. This approach can be tedious and time consuming when generating many models.
Fortunately the ASI is available to provide an effective solution for this type of problem. Our homegrown
library of keywordBlock extensions continues to adapt to our personal needs and the current state of the
interactive products. We have not yet found a case where a keyword block could not be added
automatically by using a script.

7. Post processing
7.1

Transformation of output data

In ABAQUS, element data (i.e. the components of stress, strain, and similar material variables) are written
to the ODB with respect to the default directions defined by the element conventions. For continuum
elements, global directions are used. For shell and membrane elements, surface directions are used. For
beam elements, axial and transverse directions are used. The results that are displayed in
ABAQUS/Viewer will be with respect to the default directions. If a local material coordinate system is
defined (i.e. if the *ORIENTATION option is used), results will again be written to the output database in
the default directions, however, a quaternion representing the user-defined orientation will also be written.
In this case, the results displayed in ABAQUS/Viewer will be in the directions defined by the
*ORIENTATION option.
In the case of nodal data, results are always written to the ODB in the global directions. The nodal results
displayed in ABAQUS/Viewer are always with respect to the global directions.
This approach to data storage and graphical display is helpful for the majority of post processing tasks.
Unfortunately, it does not address some fairly common situations. In response, we have developed scripts
that transform element and nodal data, after the ODB has been initially written. We have found that the
ability to transform data as a post-processing operation improves our productivity and allows us to deliver
certain results that might not otherwise be possible without custom routines.

14

2002 ABAQUS Users Conference

For example; processing element data in a local structural coordinate system that is different from a local
material coordinate system is something that we can now accomplish with our collection of transformation
utilities. Figure 5 demonstrates some results that were generated for a simply supported circular plate
subjected to a uniform pressure load. An isotropic material was defined with a principal axis skewed 45
degrees with respect to the vertical. The left viewport contains a plot of an in-plane normal component of
stress as would be typically viewed in /Viewer. The viewport on the right contains a plot of results that
have been transformed to a local cylindrical coordinate system with the origin at the center of the plate.

Prior to results transformation

After results transformation

Figure 5. Custom transformation of stress from Cartesian to cylindrical system.

7.2

Data fitting

With the ASI methods now available to read and write ODB data, and the availability of a wide range of
Python modules for numerical computations, data fitting has become more practical than it was prior to the
introduction of the ABAQUS Scripting Interface. We have developed several custom data fitting routines
to help our customers post process ABAQUS data.
For example, The left image in Figure 6 shows a deformed shape (scale factor > 1) of an injection blow
molding machine under maximum loading. Scripting was used to express the deformation in terms of a
dimensional measure of flatness as defined by the customer. The region of interest was the interface
between the upper dies (removed from the figure) and lower dies. Scripts were used to read data from the
ODB, fit the data in accordance with the flatness definition, and generate the flatness plots that are shown.

2002 ABAQUS Users Conference

15

Flatness

Deformed
shape of the
blow molding
press

of the Blow Die - Set

0.0015
0.001
0.0005

Flatness

0
-0.0005

Data fitting results for characterizing die flatness

Figure 6. An application of using the ASI for customized fitting

7.3

Working with the COM

The Component Object Model (COM) is a software integration technology developed by Microsoft that is
available in the Windows operating system. The COM provides users with an alternative to using dynamic
link libraries (DLLs) for storing collections of functions in one file to be loaded dynamically by many
different programs. It provides a relatively easy-to-use interface for sharing functionality between
programs. The Python language provides excellent support for the COM.
While our office has not yet had much of a need for taking advantage of the Python COM interface, we
have used it and anticipate that some customers will have applications that can benefit from this
functionality. A thorough FEA project would not be complete without an analysis report. Most companies
have strict rules regarding how to present analysis results in order to keep reports consistent. After
finishing a large amount of analysis, an FEA analyst often find himself doing tedious jobs like inserting
many contour plots and X-Y data generated by ABAQUS /CAE into Microsoft Word or Excel documents.
Taking advantage of automation through the COM can greatly reduce repetitive work and improve
efficiency and accuracy. We will complete our discussion by discussing one small example.
This example demonstrates using the COM to provide automatic interaction between two different
applications running on Windows: MSWord and ABAQUS. The first portion of the script uses the ASI to
open an ODB file, create a contour and X-Y plot, then save the plots into tiff files. The second portion uses
the COM interface to open MS Word and insert the contour plot and text into a document. Both ABAQUS
and Word provide a Macro recording feature. Similar to working with the ASI, Word users of the COM
interface do not need to write the code from scratch. For example, what we do is simply record the
operations from Word into a Visual Basic Macro, and then convert the macro into Python code. Figure 7
demonstrates some results that were generated from a single command.

16

2002 ABAQUS Users Conference

Figure 7. Simple application of using ABAQUS with the COM interface

8. Conclusions
The Python based ABAQUS Scripting Interface is beginning to emerge as an effective framework for
automating modeling tasks, augmenting the functionality of the ABAQUS interactive products, and
performing calculations which are outside the scope of general purpose solver or post-processor.
Regardless of industry affiliation or technical discipline, every ABAQUS analyst can benefit from
knowledge of the methods for customizing the standard product functionality. With a little practice, one
can use Python and the ABAQUS extensions to improve productivity and work quality.

2002 ABAQUS Users Conference

17