Using ABAQUS (Finite Element Method) Part 1

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 packages	Methods used	Application problems
ABAQUS	FEM (implicit, explicit)	Structural analysis, acoustics, thermal analysis, etc.
I-deas	FEM (implicit)	Structural analysis, acoustics, thermal analysis, etc.
LS-DYNA	FEM (explicit)	Structural dynamics, computational fluid dynamics, Fluid-structural interaction, etc.
Sysnoise	FEM/BEM	Acoustics (frequency domain)
NASTRAN	FEM (implicit)	Structural analysis, acoustics, thermal analysis, etc.
MARC	FEM (implicit)	Structural analysis, acoustics, thermal analysis, etc.
MSC-DYTRAN	FEM + FVM (explicit)	Structural dynamics, computational fluid dynamics, Fluid-structural interaction, etc.
ANSYS	FEM (implicit)	Structural analysis, acoustics, thermal analysis, multi-physics, etc.
ADINA DIANA	FEM (implicit)	Structural analysis, computational fluid 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 type	Description
XSYMM	Symmetry about a plane x = constant (DOFs 1, 5, 6 = 0)
YSYMM	Symmetry about a plane y = constant (DOFs 2, 4, 6 = 0)
ZSYMM	Symmetry about a plane z = constant (DOFs 3, 4, 5 = 0)
ENCASTRE	Fully clamped (DOFs 1 to 6 = 0)
PINNED	Pinned joint (DOFs 1, 2, 3 = 0)
XASYMM	Anti-symmetry about a plane x = constant (DOFs 2, 3, 4 = 0)
YASYMM	Anti-symmetry about a plane y = constant (DOFs 1, 3, 5 = 0)
ZASYMM	Anti-symmetry about a plane z = constant (DOFs 1, 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.