Introduction

Realistic finite element problems might consist of up to hundreds of

thousands, and even several millions, of elements and nodes, and therefore
they are usually solved in practice using commercially available software
packages. There is currently a large number of commercial software
packages available for solving a wide range of problems: solid and structural
mechanics, heat and mass transfer, fluid mechanics, acoustics and multi-
physics, which might be static, dynamic, linear and nonlinear. Most of these
software packages use the finite element method, or are used in combination
with other numerical methods. All these software packages are developed
based on similar methodology described in this topic, with many detailed and
fine tuned techniques and schemes. Table 13.1 lists some of the
commercially available software packages that use the FEM, Finite Volume
Method (FVM) and Boundary Element Method (BEM). This topic introduces
the use of ABAQUS, developed by Hibbitt, Karlsson & Sorenson, Inc., due to
its strong capabilities in dealing with nonlinear problems.
Table 13.1. Commercially available software packages
Software
Methods used Application problems
packages
Structural analysis, acoustics, thermal
FEM (implicit, analysis, etc.
ABAQUS
explicit)

Structural analysis, acoustics, thermal

I-deas FEM (implicit)
analysis, etc.

Structural dynamics, computational fluid

LS-DYNA FEM (explicit)
dynamics, Fluid-structural interaction, etc.

Sysnoise FEM/BEM Acoustics (frequency domain)

Structural analysis, acoustics, thermal

NASTRAN FEM (implicit)
analysis, etc.

Structural analysis, acoustics, thermal

MARC FEM (implicit)
analysis, etc.

FEM + FVM Structural dynamics, computational fluid

MSC-DYTRAN
(explicit) dynamics, Fluid-structural interaction, etc.

Structural analysis, acoustics, thermal

ANSYS FEM (implicit)
analysis, multi-physics, etc.
 Structural analysis, computational fluid
ADINA DIANA FEM (implicit)
dynamics, Fluid-structural interaction, etc.

With the development of convenient user interfaces, most finite element

software can be used as a ‘black box’, and is used by many users without
proper knowledge of the FEM. The authors have seen many cases of
misusing FEM packages, which results in simulations that can be described
as garbage in and garbage out. The danger is that the garbage output is often
covered by beautiful pictures and animations that can lead to harmful
decisions in designing an engineering system.
Understanding of the materials covered in the previous topics should shed
some light into the black box, leading to the proper use of most software
packages. This topic uses ABAQUS as an example to describe proper use of
commercial software packages from the user’s point of view.Throughout the
case studies in this topic, the analyses are carried out using
ABAQUS/Standard finite element software (version 6.1). There are other
modules in the ABAQUS finite element package, including ABAQUS/Explicit,
ABAQUS/CAE and ABAQUS/Viewer. ABAQUS/Explicit is mainly used for
explicit dynamic analysis. ABAQUS/CAE is an interactive preprocessor that
can be used to create finite element models and the associated input file for
ABAQUS. ABAQUS/Viewer is a menu-driven interactive post-processor for
viewing the results obtained from ABAQUS/Standard and ABAQUS/Explicit.
In this topic, however, the focus will be on the writing of the
ABAQUS/Standard input file, and ABAQUS/Standard will from now on just be
called ABAQUS. This topic cannot and will not try in any way to replace the
extensive and excellent manuals provided together with the ABAQUS
software. This topic will just serve as a general guide especially suited for
beginner users to have a quick start in using ABAQUS, without going through
the details of thick manuals. It is hoping that readers, after reading this topic,
will have an even better understanding of the finite element concepts being
implemented in the finite element software. It should be noted that though
only ABAQUS is introduced in this topic, the use of other software packages
is actually similar in many ways, except for the detailed format of inputs and
outputs.

Basic Building Block: Keywords and Data Lines

The first step to writing an ABAQUS input file is to know the way in which
data is included in the input file. In ABAQUS, the data definitions are
expressed in what are termed ‘option blocks’ or ‘groups of cards’. Basically, it
is thus called because the user has the option to choose particular data
blocks that are relevant for the model to be defined. Each option block can be
considered to be a basic building block that builds up the entire input file. The
option block is introduced by a keyword line, and if the option block requires
data lines, these will follow directly below the keyword line. The general layout
of a particular option block is shown in Case 1 with the definition of beam
elements as an example.
Keyword lines begin with an asterisk, *, followed by the name of the block. In
this case, to define elements in the element block identified with the keyword
ELEMENT. Subsequent information on the keyword line provides additional
parameters associated with the block being used. In this case, it is necessary
to tell ABAQUS what type of elements are being used (B23 – 2 node, 1D
Euler-Bernoulli beam element), and the elements are grouped up into a
particular set with the arbitrary given name ‘BEAM’. This grouping of entities
into sets is a very convenient tool, which the analyst will use very often. It
enables the analyst to make references to the set when defining certain option
blocks.

The data lines basically provide data, if required, that is associated with the
option block used. In the example in Case 1, element identification (i.d.) and
the nodes that make up the element are the necessary data required. Note
that the information provided in the data lines would vary with some of the
parameters defined in the keyword line. For example, if the element type
being used is a 2D plane stress element, then the data lines would require
different data, as shown in Case 2.

Note that, in this case, the element type CPS4 which represents four-nodal,
2D solid elements is being used, and correspondingly, the data lines must
include the element i.d. (as before), and four nodes that make up each
element instead of two for the case of the beam element previously.

Using Sets
In the last section, it was seen in Case 1 that elements can be grouped into
a set for future reference by other option blocks. A set can be a grouping of
nodes or a grouping of elements. The analyst will usually provide a name for
the set that contains between 1-80 characters. For example, in Case 1,
‘BEAM’ is the name of the set containing elements 1 and 2; and in Case 2,
‘PLSTRESS’ is the name of the set containing elements 1 and 2. In both
examples, the sets are defined together with the definition of the elements
themselves in the element block. However, sets can also be defined as a
separate block on their own. In Case 3, the pinned support of the 1D beam is
to be defined. Nodes 1 and 11 (provided in the data line for the ‘NSET’ block)
are first grouped in the node set called ‘SUPPORT’. Then using the
‘BOUNDARY’ option block, the node set, ‘SUPPORT’ is referenced to
constrain the DOFs, 1 and 2 (x translation and y translation) to zero. In other
words, rather than having four data lines for the two nodes 1 and 11 (each
node having to constrain two DOFs), we now have only two lines with the
reference to the node set ‘SUPPORT’. Another thing to note in this example is
the use of comment lines. Comment lines exist in ABAQUS too, just as in
most programming languages. Comment lines begin with two asterisks, **,
and whatever follows in that line after that will not be read by ABAQUS as
input information defining the model.

This is, of course, a very simple case, and the reduction in the number of
data lines from four to two may not seem very significant. However, imagine if
the model is a huge 3D model, and one whole surface containing about 100
nodes is to be prescribed a boundary condition. If the nodes on this surface
were not grouped into node sets, then the user would end up with 100 x (No.
of DOFs to be constrained) data lines just to prescribe a boundary condition.
A more efficient way, of course, is to group the nodes in this particular surface
in a node set, and then like Case 3, write down the data lines referencing the
node set to be constrained. In this way, the number of data lines for the
‘BOUNDARY’ block would be equal to the number of DOFs to be constrained.
Similar use of sets can be applied to elements as well. One common use of
element sets (ELSET) is the referencing of element properties to the elements
in a particular set (see the example in Section 13.5.3). Sets are thus the basic
referencing tool in ABAQUS.

Abaqus Input Syntax Rules

The previous section introduced the way in which data are organized in the
ABAQUS input file. Like most programming languages, there are certain rules
which the entries into the input file must follow. A violation of these rules
would generally result in syntax error when ABAQUS is run, and most of the
time the analysis will not be carried out. So far, it has been shown that
ABAQUS generally has three types of entries in the input file: the keyword
lines, the data lines and the comment lines. Comment lines generally do not
need many rules, except that it must begin with two asterisks (**) in columns 1
and 2. This section therefore describes the rules that apply to all keywords
and data lines.
Keyword Lines
The following rules apply when entering a keyword line:
•    The first non-blank character of each keyword line must be an asterisk (*).

•    The keyword must be followed by a comma (, ), if any further parameters

are to be included in the line.

•    Parameters are separated by commas.

•    Blanks on a keyword line are ignored.

•    A line can include no more than 256 characters including blanks.

•    Keywords and parameters are not case sensitive.

•    Parameter values are not usually case-sensitive. The only exceptions to
this rule are those imposed externally on ABAQUS, such as file names on
case-sensitive operating systems.

•    If a parameter has a value, the equal sign (=) is used. The value can be an
integer, a floating point number, or a character string, depending on the
context. For example,

• Continuation of a keyword line is sometimes necessary, especially when

there is a large number of parameters. If the last character of a keyword line is
a comma, the next line is treated as a continuation line. For example, the
example stated in the previous rule can also be written as

Data Lines
The data lines must immediately follow a keyword line if they are
required. The following rules apply when entering a data line:
•    A data line can include no more than 256 characters including blanks.
•    All data items are separated by commas. An empty data field is specified
by omitting data between commas. ABAQUS will use values of zeros for any
required numeric data that are omitted, unless there is a default value
allocated. If a data line contains only a single data item, the data item should
be followed by a comma.

•    A line must contain only the number of items specified.

•    Empty data fields at the end of a line can be ignored.

•    Floating point numbers can occupy a maximum of 20 spaces including the
sign, decimal point, and any exponential notation.

•    Floating point numbers can be given with or without an exponent. Any
exponent, if input, must be preceded by E or D and an optional (-) or (+) to
indicate the sign of the exponent.

•    Integer data items can occupy a maximum of 10 digits.

•    Character strings can be up to 80 characters long and are not case-
sensitive.

•    Continuation lines are allowed in specific instances, such as when defining
elements with a large number of nodes. If allowed, such lines are indicated by
a comma as the last character of the preceding line.

Labels
Examples of labels are set names, surface names and material names, and
they are case-sensitive, unlike the other entries in the keyword line. Labels
can be up to 80 characters long. All spaces within a label are ignored unless
the label is enclosed in quotation marks, in which case all spaces within the
label are maintained. A label that is not enclosed within quotation marks may
not include a period (.), and should not contain characters such as commas
and equal signs. If a label is defined using quotation marks, the quotation
marks are stored as part of the label. Any subsequent reference or use of the
label should also include the quotation marks. Labels cannot begin and end
with a double underscore (e.g._ALU_).
This label format is reserved for use internally within ABAQUS.

Defining a Finite Element Model in Abaqus

Though the use of a preprocessor like ABAQUS/CAE or PATRAN can be
helpful in creating the finite element model and generating the input file for
complex models, the analyst will still often find that the preprocessor cannot
automatically generate many functions available in ABAQUS, which are
required in the input file. In a way, today’s preprocessors mainly cater for the
most common problems. A specific analysis will often require more than just
the usual analysis steps, and this is when an analyst will find that knowing the
basic concepts of writing an input file will enable him or her to either write a
whole input file for the specific problem, or to modify the existing input file that
is generated by the preprocessor.
An ABAQUS input file is an ASCII data file which can be created or edited
using any text editor. The input file contains two main sets of data: model data
and history data. The model data consists of data defining the finite element
model. This part of the input file defines the elements, nodes, element
properties, material properties and any other data that specifies the model
itself. Looking at the input files provided for the case studies included in
previous topics, it should be noted that all the data provided before the
‘*STEP’ line is considered as the model data. The history data on the other
hand defines what happens to the finite element model. It tells ABAQUS the
events the model has gone through, the loadings the model has, the type of
response that should be sought for, and so on. In ABAQUS, the history data is
made up of one or more steps. Each step defines the analysis procedures by
providing the required parameters. It is possible and in fact quite common to
have multiple steps to define a whole analysis procedure. For example, to
obtain a steady-state dynamic response due to a harmonic excitation at a
given frequency by modal analysis, one must first obtain the eigenvalues and
eigenvectors. This can be defined in a step defined by *FREQUENCY, which
calls for the eigenvector extraction analysis procedure. Following that, another
step defined by * STEADY STATE DYNAMICS is necessary that calls for the
modal analysis procedure to solve for the response under a harmonic
excitation. As such, the history data can be said to make up of series of steps,
which in a way tells the history of the analysis procedure. This section will
describe in more detail how a basic model can be defined in ABAQUS. Input
files defining most problems have the same basic structure:
1.    An input file must begin with the *HEADING option block, which is used to
define a title for the analysis. Any number of data lines can be used to give
the title.
2.    After the heading lines, the input file would usually consist of the model
data, which is the node definition, element definition, material definition, initial
conditions and so on.
3.    Finally, the input file would consist of the history data, in which is defined
the analysis type, loading, output requests, and so on. Usually, the *STEP
option is the dividing point in the input file between the model and history
data. Everything appearing before the *STEP option will be considered as
model data, and everything after will be considered as the history data.
The following outlines some of the options and data that can be included in
the model and history data. This topic will not elaborate on all the available
options, and if required, the user is recommended to refer to the software’s
user manual. Elaboration will be done on some of the necessary options for a
basic finite element model later.

Model Data
Some of the data that must be included in the model data are as follows:
•    Geometry of the model: The geometry of the model is described by its
elements and nodes.

•    Material definitions, which are usually associated with parts of the
geometry.

Other optional data in the model data section are:

•    Parts and an assembly: the geometry can be divided into parts, which
are positioned relative to one another in an assembly.
•    Initial conditions: non-zero initial conditions such as initial stresses,
temperatures or velocities can be specified.
•    Boundary conditions: zero-valued boundary conditions (including
symmetry conditions) can be imposed on the model.
•    Constraints: linear constraint equations or multi-point constraints can be
defined.
•    Contact interactions: contact conditions between surfaces or parts can
be defined.
•    Amplitude definitions: amplitude curves for which the loads or boundary
conditions are to follow can be defined.
•    Output control: options for controlling model definition output to the data
file can be included.
•    Environment properties: environment properties such as the attributes of
a fluid surrounding the model can be defined.
•    User subroutines: user-defined subroutines, which allow the user to
customize ABAQUS, can be defined.
•    Analysis continuation: it is possible to write restart data or to use the
results from a previous analysis and continue the analysis with new model or
history data.

History Data
As mentioned, in the history data, the entries are divided into steps. Each
step begins with the *STEP option and ends with the *END STEP option.
There are generally two kinds of step that can be defined in ABAQUS – the
general response analysis steps (can be linear or nonlinear); and the linear
perturbation steps. A general analysis step is one in which the effects of any
nonlinearities present in the model can be included. The starting condition for
each general analysis step is the ending condition from the last general
analysis step. The response of each general analysis step contributes to the
overall history of the response of the model. A linear perturbation analysis
step, on the other hand, is used to calculate the linear perturbation response
from the base state. The base state is the present state of the model at the
end of the last general analysis response. For the perturbation step, the
response does not contribute to the history of the overall response, and hence
can be called for at any time in between general steps. For cases where the
general step or the linear perturbation step is the first step, then the initial
conditions defined will define the starting condition or the base state,
respectively. The following is a list of the analysis types that uses linear
perturbation procedures:
•    *BUCKLE (Eigenvalue buckling prediction)

•    * FREQUENCY (Natural frequency extraction)

•    *MODAL DYNAMIC (Transient modal dynamic analysis)

•    * STEADY STATE DYNAMICS (Modal steady-state dynamic analysis)

•    * STEADY STATE DYNAMICS, DIRECT (Direct steady-state analysis)

•    * RESPONSE SPECTRUM (Response spectrum analysis)

•    *RANDOM RESPONSE (Random response analysis)

Except for the above analysis types and for the * STATIC (where both general
and perturbation steps can be used), all other analysis types are general
analysis steps.

Some of the data that must be included in the history data or within a
step are:
•    Analysis type: an option to define the analysis procedure type which
ABAQUS will perform. This must appear immediately after the *STEP option.
Other optional data include:
•    Loading: some form of external loading can be defined. Loadings can be
in the form of concentrated loads, distributed loads, thermal loads, and so on.
Loadings can also be prescribed as a function of time following the amplitude
curve defined in the model data. If an amplitude curve is not defined,
ABAQUS will assume that the loading varies linearly over the step (ramp
loading), or that the loading is applied instantaneously at the beginning of the
step (step loading).
•    Boundary conditions: zero-valued or non-zero boundary conditions can
be added, modified or removed. Note that if defined in the model data, only
zero-valued and symmetrical boundary conditions can be included.
•    Output control: controls the requested output from the analysis. Output
variables depend upon the type of analysis and the type of elements used.
•    Auxiliary controls: options are provided to allow the user to overwrite the
solution controls that are built into ABAQUS.
•    Element and surface removal/reactivation: portions of the model can be
removed or reactivated from step to step.

Example of Cantilever Beam Problem

One of the best ways of learning about and understanding the ABAQUS
input file is to follow an example. We shall illustrate with a simple example of
modelling a cantilever beam subjected to a downward force, as shown in
Figure 13.1. The above problem can be modelled using 1D beam elements,
and the finite element mesh will be as follows:
As mentioned, the first thing to include in the input file would be the *
HEADING option. The data line after the * HEADING keyword line briefly
describes the problem.

Next will be writing the model data. First, the nodes of the problem must be
defined, since elements must be made up of nodes, and both nodes and
elements make up the geometry of the problem.

Figure 13.1. Cantilever beam under downward force.

Figure 13.2. Cantilever beam meshed with ID, two-nodal, beam elements.

Using the *NODE option, the nodes at the end are first defined. We then use
the option *NGEN to generate evenly distributed nodes between the first and
last nodes. *NGEN is one of the several mesh generation capabilities
provided by ABAQUS. We could also define all 11 nodes individually by
specifying their coordinates, but using *NGEN would be more efficient for
large problems. So we have now defined 11 nodes uniformly along the length
of the beam. Next, the elements would be defined:

Here, the *ELEMENT option is used to define the first element that consists of
nodes 1 and 2. The TYPE parameter is included to specify what type of
element is being defined. In this case, B23 refers to a 1D beam elment in a
plane with cubic interpolation. Users can refer to the ABAQUS manual for the
element library to check the codes for other element types. Similar to the
definition of nodes, *ELGEN is used to generate 1-10 elements subsequently.
The elements are then grouped into a node set called RECT_BEAM. This will
make the referencing of element properties much easier later. So we have
now defined 11 nodes and 10 elements as shown in Figure 13.2.
The next step will be to define the element properties:
In the *BEAM SECTION keyword line, the element set RECT_BEAM
defined earlier is now referenced, meaning that the elements grouped under
RECT_BEAM will all have the properties defined in this option block. We also
provide the information that the beam has a rectangular (RECT) cross-
section. There are other cross-sections available in ABAQUS, such as circular
cross-sections (CIRC), trapezoidal cross-sections (TRAPEZOID), closed thin-
walled sections (BOX, HEX and PIPE) and open thin-walled sections (I-
section and L-section). ABAQUS also provides for a ‘general’ cross-section by
specifying geometrical quantitites necessary to define the section. The
material associated with the elements is also defined as ALU, where the
properties will be defined later. It is a good time to note that, unlike most
programming languages, the ABAQUS input file need not follow a top-down
approach when ABAQUS is assessing the file. For example, the material ALU
is already referenced at this point under the *BEAM SECTION option block,
though its material properties are actually defined further down the input file.
There will not be any error stating that the material ALU is invalid regardless
of where the material is defined unless it is not defined at all throughout the
input file. This is true for all other entries into the input file. Let us now look at
the data lines. The first data line in the *BEAM SECTION basically defines the
dimensions of the cross-section (0.025 x 0.04 m). Note that the dimensions
here are converted to metres to be consistent with the coordinates of the
nodes. The second data line basically defines the direction cosines indicating
the local beam axis. What is given is the default values, and this line can
actually be omitted in this case.
The next entry in the model data would be the material properties
definition:

The material for our example is aluminium, and we name it ALU for short.
All the properties option block will follow after the *MATERIAL option block,
which does not require any data lines by itself. The *ELASTIC option defines
elastic properties, and TYPE=ISOTROPIC defines the material as an isotropic
material, i.e. the material properties are the same in all directions. The data
line for the * ELASTIC option includes the values for the Young’s modulus and
Poisson’s ratio. Depending upon the type of analysis carried out, or the type
of material being defined, other properties may need to be defined. For
example, if a dynamic analysis is required, then the *DENSITY option would
also need to be included; or when the material exhibits viscoelastic behaviour,
then the
* VISCOELASTIC option would be required.

At this point, we have almost completed describing the model in the model
data. What is left are the boundary conditions. Note that the boundary
conditions can also be defined in the history data. What can be defined in the
model data is only the zero valued conditions.

There is actually more than one way of defining a *BOUNDARY. What is

shown is the most direct way. The first entry into the data line is the node i.d.
or the name of the node set, if one is defined. In this case, since it is only one
single node, there is no need for a node set. But many times, a problem might
involve a whole set of nodes where the same boundary conditions are
applied. It would thus be more convenient to group these nodes into a set and
referenced in the data line. The second entry is the first DOF of the node to be
constrained, while the third entry is the last DOF to be constrained. In
ABAQUS, for displacement DOFs, the number 1, 2 and 3 would represent the
translational displacements in the x, y and z-directions, respectively, while the
numbers 4, 5 and 6 would represent the rotations about the x, y and z-axes,
respectively. Of course, depending on the type of element used and the type
of analysis carried out, there may be other DOFs represented by other
numbers (refer to the ABAQUS manual). For example, if a piezoelastic
analysis is carried out using piezoelastic elements, there is an additional DOF
(other than the displacement DOFs) number 9 representing the electric
potential of the node. In this case, all the DOFs from 1 to 6 will be constrained
to zero (fourth entry in the data line). Strictly speaking, the DOFs available for
the 1D planar, beam element in ABAQUS are only 1, 2 and 6 since the others
are considered out of plane displacements. Since we constrained all six
DOFs, ABAQUS will just give a warning during analysis that the constraints
on DOFs 3, 4 and 5 will be ignored, since they do not exist in this context.
There are numerous parameters that can actually be included in the
keyword line of the *BOUNDARY option if they are required (refer to the
ABAQUS manuals for details). For example, the boundary condition can be
made to follow an amplitude curve by including AMPLITUDE = Name of
amplitude curve definition in the keyword line. ABAQUS also provides for
certain standard types of zero-valued boundary conditions. For example, the
above boundary condition can also be written as

The word ENCASTRE used in the data line represents a fully built-in

condition, which also means that DOFs 1-6 are constrained to zero. Other
standard boundary conditions are listed in Table 13.2. After defining the
boundary condition, we have now completed what is required for the model
data of the input file.
We now need to define the history data. As mentioned, the history data
would begin with the *STEP option. In this example, we would be required to
obtain the displacements of the beam as well as the stress along the beam
due to the downward force. One step would be sufficient here and the loading
will be static:

The perturbation parameter following the *STEP option basically tells

ABAQUS that only a linear response should be considered. The * STATIC
option specifies that a static analysis is required.

Table 13.2. Standard boundary condition types in ABAQUS

Boundary condition
Description
type
Symmetry about a plane x = constant (DOFs 1, 5, 6
XSYMM
= 0)

Symmetry about a plane y = constant (DOFs 2, 4, 6

YSYMM
= 0)

Symmetry about a plane z = constant (DOFs 3, 4, 5

ZSYMM
= 0)

ENCASTRE Fully clamped (DOFs 1 to 6 = 0)

PINNED Pinned joint (DOFs 1, 2, 3 = 0)

Anti-symmetry about a plane x = constant (DOFs 2,

XASYMM
3, 4 = 0)

Anti-symmetry about a plane y = constant (DOFs 1,

YASYMM
3, 5 = 0)

Anti-symmetry about a plane z = constant (DOFs 1,

ZASYMM
2, 6 = 0)

The next thing to include will be the loading conditions:

ABAQUS offers many types of loading. *CLOAD represents concentrated
loading, which is the case for our problem. Other types of loading include
*DLOAD for distributed loading, *DFLUX for distributed thermal flux in
thermal-stress analysis, and *CFCHARGF for concentrated electric charge for
nodes of piezoelectric elements. The first entry in the data line is the node i.d.
or the name of the node set if defined, the second is the DOF the load is
applied to, and the third is the value of the load. In our case, since the force is
acting downward, it is acting on DOF 2 with a negative sign following the
convention in ABAQUS. Most loadings can also follow an amplitude curve
varying with time by including AMPLITUDE = Name of amplitude curve
definition in the keyword line. This is especially so if transient, dynamic
analysis is required.
For this problem, there is not much more data to include in the history data
other than the output requests. The user can request the type of outputs he or
she wants by indicating as follows:

From what we learned from the finite element method, we can actually
deduce that certain output variables are direct nodal variables like
displacements, while others like stress and strain are actually determined as a
distribution in the element using the shape functions. In ABAQUS, this
difference is categorized into nodal output variables and element output
variables. *NODF PRINT outputs the results of the required nodal variables in
an ASCII text file (.dat file), while the *NODF FILE ouputs the results in a
binary format (.fil file). The binary format can be read by post-processors in
which the results can be displayed. Similarly, *ELFMENT PRINT outputs
element variables in ASCII format, while *F,LFMF,NT FILE outputs them in
binary format. A list of the different output variables can be obtained in the
ABAQUS manuals. For our case, U in the data lines for *NODF PRINT and
*NODF FILF will output all the components of the nodal displacements. S and
F represent all the components of stress and strain, respectively. So if the
analysis is run, there will be altogether three tables: one showing the nodal
displacements, one showing the stresses in the elements, and the last one
showing the strains in the elements. The last thing to do now is end the step
by including *FNDSTFP. If multiple steps are present, this would separate the
different steps in the history data.