The Abaqus benchmark problems are intended to provide an estimate
of the performance that can be expected when running representative
Abaqus analysis jobs on different computer platforms. The different
Abaqus products and different types of Abaqus analyses are appropriate
for different classes of machines and stress machines differently. The
benchmarks are organized with the intention of making it possible for
users to view the subset of the benchmark data appropriate to their
usage of Abaqus.
The benchmark problems listed here are available upon request. If
you are a customer, see Abaqus Answer 2342 for instructions on obtaining
the input files associated with these benchmark problems. If you are
a hardware vendor and would like to submit performance data please
contact .
NOTE: The Abaqus benchmark problems may change
between releases. Therefore the timing data presented on these pages
should not be directly compared with benchmark data obtained using
other versions of Abaqus.
All times are given in seconds and include the time required for the main
analysis executables (standard.exe and explicit.exe), the analysis input file
processor (pre.exe), and the Abaqus/Explicit packager (package.exe).
The Abaqus benchmark suite is designed with the intent of providing users of
Abaqus information about how Abaqus will perform on various hardware platforms
available on the market. As different Abaqus jobs will stress the hardware in
different ways, providing a benchmark suite that is both comprehensive and
relatively easy to understand is a challenging task. In order to make good use
of the data on this page, users should be careful to understand how the benchmarks
are organized and to use data that is representative of their problems.
There are two basic variables a user needs to consider when looking at
benchmarks. The first is the type of Abaqus job. Different Abaqus jobs stress
hardware in different ways. A user running eigenvalue analyses with Abaqus/Standard
will want to focus on different aspects of a hardware purchase than a user
running an electronics drop test with Abaqus/Explicit. The second variable a
user must consider is the type of hardware being considered. In the following
section the basic categories of Abaqus job and hardware used in presenting
benchmark data are described.
Hardware Categories
Workstation: The first hardware category is workstations. Typically
workstations have either 2 or 4 cores and sit on a user's desktop. Workstations
are typically used for running jobs that do not run for a very long time
(over night being the maximum) or use a very large amount of memory. Workstations
are typically configured with 2, 4, or possible 8 GB of physical memory.
In a typical workstation configuration a user is likely to be doing a number
of things on the machine at the same time. During the time that the 6.7 release
is in use, it is anticipated that quad-core workstations will become widely
available, and users may start to have 2P/quad-core (8 cores total) workstations.
Compute Server: The second hardware category is compute servers. Computer
servers are machines that are dedicated to computing long-running or large
Abaqus jobs as efficiently as possible. In past years compute servers were
large SMP machines that were typically shared between many users. More recently
users have been migrating to having a farm of SMP compute servers each of which
runs a single Abaqus job at a time. This has also led into the more recent usage
of clusters, which means dedicating multiple compute servers to a single Abaqus
job. Compute clusters typically feature a high-speed private network which connects
the servers. While the trend has been away from multi-user servers, this model
is by no means extinct. Readers should note that compute clusters are typically
configured to function as a single multi-user server, but this is a server
that physically consists of a number of compute hosts each of which will be dedicated
to a single task at any time.
Abaqus Job Categories
Abaqus/Standard Nonlinear: Performance of nonlinear problems in Abaqus/Standard
is typically driven by two factors: problem size and number of iterations
required to complete a simulation. A large problem is one with a large number of nodes
and elements, or the related measure of number of degrees of freedom.
As the size of a problem grows, the cost of an individual iteration, both
in terms of runtime and memory requirements, grows, making hardware performance
critical to solving large problems. The runtime, but not memory cost, for a problem
is also dictated by the number of iterations required to find a solution. A medium-sized
problem may have a very long runtime if the number of iterations required for the
problem is very high.
The cost of an individual iteration in Abaqus/Standard is split between the cost
of doing element computations and the cost of solving a system of linear equations. As
problems grow larger the cost of the linear equation solution will dominate execution
time to a greater extent. The Abaqus sparse linear equation solver executes a large
number of "BLAS3" type operations which execute well on machines that can very
efficiently performance matrix-matrix multiplications. Element computations are a much
bigger factor in smaller problems. Efficient management of element computations
tends to stress the ability of a machine to deliver data to the processor in
addition to the speed of floating point computation.
As Abaqus/Standard problems get larger, the temporary data required by the linear
equation solver is written to disk. For this reason disk performance is often an
important performance consideration for Abaqus/Standard.
Both the element computations and linear equation solution can be executed in
parallel. Parallelization tends to be more effective with increasing problem size.
Problems under 100,000 degrees of freedom (DOF) will typically not show a decrease
in execution time when more than 2 cores are used a problem. Problems under
2 million DOF will typically not show significant speedup beyond 16 cores. Problems
with a small number of iterations will also not show good overall speedup with
added cores as only the actual iterations are executed in parallel. The input
file preprocessor and initialization code execute on a single core.
Abaqus/Standard Linear: Linear problems come is several forms.
The first is linear static (perturbation) problems. Unless very large these problems do
not typically have very long runtimes and are thus not a significant focus of the
Abaqus benchmarks. Of greater interest are linear dynamics problems, and in particular
the eigensolution required for most linear dynamics problems is a costly operation
that is a focus of the benchmarks.
For a number of years, the Lanczos solver has been the primary means of solving
large eigenvalue problems with Abaqus. For large problems the speed of the Lanczos
solver is highly dependent of mangement of temporary data (used only during the
analysis) which is written to disk. For smaller jobs this data can be kept in memory,
but the solution time for large eigenvalue jobs is highly dependent on the I/O
performance for a given machine.
The AMS eigensolver has performance characteristics that are closer to the
linear equation solver than to Lanczos. AMS eigensolver jobs are still sensitive to
I/O performance, but not nearly to the extent of the Lanczos solver.
Parallelization is generally not as effective for the Abaqus eigensolvers as for
nonlinear solutions using Abaqus/Standard and Abaqus/Explicit. Benchmark results are
presented for Lanczos eigensolution, but users should be careful in looking to
parallel execution to improve eigensolution performance.
Abaqus/Explicit: Abaqus/Explicit characteristically runs a large number of
very fast increments. Performance for Abaqus/Explicit is typically dictated by a
combination of floating point performance and memory access speeds. When running
multi-core on a single node, Abaqus/Explicit jobs may exhaust the memory bandwidth
available on a given system.
Parallelization for Abaqus/Explicit is generally quite effective. As with
Abaqus/Standard, Abaqus/Explicit requires a minimum per-core problem size to parallelize
effectively. It is typically recommended that there must be a minimum of roughly 5,000
elements per core for an Explicit job to run effectively in parallel. Beyond this basic
limit, parallel speedup in Abaqus/Explicit is typically affected by how well work can be
balanced between cores on a system. The division of computation between cores (load
balance) is typically dependent on features included in the Explicit model.
Presentation of Benchmark Data
Workstation Benchmarks: The workstation benchmarks consist of the smaller
Abaqus jobs. These are executed on relatively low numbers of cores. Since workstations
are generally purchased with an eye towards general use, no distinction is made between
Abaqus/Standard and Abaqus/Explicit execution.
Abaqus/Standard Server Benchmarks: The Abaqus/Standard server benchmarks
feature the larger nonlinear Abaqus/Standard jobs. The focus here is on execution of medium
to large sized jobs running on compute servers. In the case of clusters or smaller
SMP machines, the assumption is made that a single host will be dedicated to running
a single Abaqus job. For large SMP machines where multiple Abaqus jobs may be
executed on a single host, times are given both for a single job running on the
machine (sequential execution) and the throughput situation when multiple jobs are
run simultaneously (simultaneous execution).
Abaqus/Explicit Server Benchmarks: The Abaqus/Standard server benchmarks
feature longer running Abaqus Explicit jobs. As with Abaqus/Standard, the assumption
is made that on clusters and smaller SMP machines, a single machine will be dedicated
to a single Abaqus job. For larger SMP machines both sequential and throughput times
are given.
Abaqus/Standard Linear Benchmarks: The Abaqus/Standard linear benchmarks
focus on eigensolutions using the Lanczos and AMS eigensolvers.
Benchmark Problem Descriptions
Abaqus/Standard Benchmark Problems
The problems described below provide an estimate of the
performance that can be expected when running Abaqus/Standard on
different computers. The jobs are representative of typical
Abaqus/Standard applications including linear statics, nonlinear
statics, and natural frequency extraction.
S1: Plate with gravity load
This benchmark is a linear static analysis of a
plate with gravity loading. The plate is meshed with
second-order shell elements of type S8R5 and uses a linear
elastic material model. Edges of the plate are fixed. There is
no contact.
S1
Input file name:
s1.inp
Increments:
1
Iterations:
1
Degrees of freedom:
1,085,406
Floating point operations:
1.89E+011
Minimum memory requirement:
587 MB
Memory to minimize I/O:
2 GB
Disk space requirement:
2 GB
S2: Flywheel with centrifugal load
This benchmark is a mildly nonlinear static
analysis of a flywheel with centrifugal loading. The flywheel
is meshed using first-order hexahedral elements of type C3D8R
and uses an isotropic hardening Mises plasticity material
model. There is no contact. The nonlinearity in this problem
arises from localized yielding in the vicinity of the bolt
holes.
Two versions of this benchmark are provided. Both versions
are identical except that one uses the direct sparse solver
and the other uses the iterative
solver.
S2a: Direct solver
version
Input file name:
s2a.inp
Increments:
6
Iterations:
12
Degree of freedom:
474,744
Floating point operations:
1.86E+012
Minimum memory requirement:
733 MB
Memory to minimize I/O:
849 MB
Disk space requirement:
4.55 GB
S2b: Iterative
solver version
Input file name:
s2b.inp
Increments:
6
Iterations:
11
Degrees of freedom:
474,744
Floating point operations:
8.34E+010
Minimum memory requirement:
2.8 GB
Memory to minimize I/O:
NA
Disk space requirement:
387 MB
S3: Impeller frequencies
This benchmark extracts the natural frequencies
and mode shapes of a turbine impeller. The impeller is meshed
with second-order tetrahedral elements of type C3D10 and uses
a linear elastic material model. Frequencies in the range from
100 Hz. to 20,000 Hz. are requested.
Three versions of this benchmark are provided: a 360,000
DOF version that uses the Lanczos eigensolver, a 1,100,000 DOF
version that uses the Lanczos eigensolver, and a 1,100,000 DOF
version that uses the AMS
eigensolver.
S3a: 360,000 DOF
Lanczos eigensolver version
Input file name:
s3a.inp
Degrees of freedom:
362,178
Floating point operations:
3.42E+11
Minimum memory requirement:
384 MB
Memory to minimize I/O:
953 MB
Disk space requirement:
4.0 GB
S3b: 1,100,000 DOF
Lanczos eigensolver version
Input file name:
s3b.inp
Degrees of freedom:
1,112,703
Floating point operations:
3.03E+12
Minimum memory requirement:
1.33 GB
Memory to minimize I/O:
3.04 GB
Disk space requirement:
23.36 GB
S3c: 1,100,000 DOF
AMS eigensolver version
Input file name:
s3c.inp
Degrees of freedom:
1,112,703
Floating point operations:
3.03E+12
Minimum memory requirement:
1.33 GB
Memory to minimize I/O:
3.04 GB
Disk space requirement:
19.3 GB
S4: Cylinder head bolt-up
This benchmark is a mildly nonlinear static
analysis that simulates bolting a cylinder head onto an engine
block. The cylinder head and engine block are meshed with
tetrahedral elements of types C3D4 or C3D10M, the bolts are
meshed using hexahedral elements of type C3D8I, and the gasket
is meshed with special-purpose gasket elements of type GK3D8.
Linear elastic material behavior is used for the block, head,
and bolts while a nonlinear pressure-overclosure relationship
with plasticity is used to model the gasket. Contact is
defined between the bolts and head, the gasket and head, and
the gasket and block. The nonlinearity in this problem arises
both from changes in the contact conditions and yielding of
the gasket material as the bolts are tightened.
Three versions of this benchmark are provided: a 700,000
DOF version that is suitable for use with the direct sparse
solver on 32-bit systems, a 5,000,000 DOF version that is
suitable for use with the direct sparse solver on 64-bit
systems, and a 5,000,000 DOF version that is suitable for use
with the iterative solver on 64-bit
systems.
S4a: 700,000 DOF
direct solver version
Input file name:
s4a.inp
Increments:
1
Iterations:
5
Degrees of freedom:
720,059
Floating point operations:
5.77E+11
Minimum memory requirement:
895 MB
Memory to minimize I/O:
3 GB
Disk space requirement:
3 GB
S4b: 5,000,000 DOF
direct solver version
Input file name:
s4b.inp
Increments:
1
Iterations:
5
Degrees of freedom:
5,236,958
Floating point operations:
1.14E+13
Minimum memory requirement:
4 GB
Memory to minimize I/O:
20 GB
Disk space requirement:
23 GB
S4c: 5,000,000 DOF
iterative solver version
Input file name:
s4c.inp
Increments:
1
Iterations:
3
Degrees of freedom:
5,248,154
Floating point operations:
3.74E+11
Minimum memory requirement:
16 GB
Memory to minimize I/O:
NA
Disk space requirement:
3.3 GB
S5: Stent expansion
This benchmark is a strongly nonlinear static
analysis that simulates the expansion of a medical stent
device. The stent is meshed with hexahedral elements of type
C3D8 and uses a linear elastic material model. The expansion
tool is modeled using surface elements of type SFM3DR. Contact
is defined between the stent and expansion tool. Radial
displacements are applied to the expansion tool which in turn
cause the stent to expand. The nonlinearity in this problem
arises from large displacements and sliding contact.
Note: Abaqus, Inc. would like to acknowledge Nitinol
Devices and Components for providing the original finite
element model of the stent. The stent model used in this
benchmark is not representative of current stent
designs.
S5
Input file name:
s5.inp
Increments:
21
Iterations:
91
Degrees of freedom:
181,692
Floating point operations:
1.80E+009
Minimum memory requirement:
NA
Memory to minimize I/O:
NA
Disk space requirement:
NA
S6: Tire footprint
This benchmark is a strongly nonlinear static
analysis that determines the footprint of an automobile tire.
The tire is meshed with hexahedral elements of type C3D8,
C3D6H, and C3D8H. Linear elastic and hyperelastic material
models are used. Belts inside the tire are modeled using rebar
layers and embedded elements. The rim and road surface are
modeled as rigid bodies. Contact is defined between the tire
and wheel and the tire and road surface. The analysis sequence
consists of three steps. During the first step the tire is
mounted to the wheel, during the second step the tire is
inflated, and then during the third step a vertical load is
applied to the wheel. The nonlinearity in the problem arises
from large displacements, sliding contact, and hyperelastic
material behavior.
S6
Input file name:
s6.inp
Increments:
41
Iterations:
177
Degrees of freedom:
729,264
Floating point operations:
NA
Minimum memory requirement:
397 MB
Memory to minimize I/O:
940 MB
Disk space requirement:
NA
Abaqus/Explicit Benchmark Problems
The problems described below provide an estimate of the
performance that can be expected when running Abaqus/Explicit on
different computers. The jobs are representative of typical
Abaqus/Explicit applications including high-speed dynamic impact
events and quasi-static events with complicated contact conditions.
The number of increments listed in the tables below are approximate
and can vary somewhat depending on the hardware platform and the
number of parallel domains.
E1: Car crash
This benchmark consists of passenger car
impacting a rigid wall. The car is meshed primarily with shell
elements of type S3RS and S4RS with isotropic hardening Mises
plasticity material behavior. The various compenents of the
car are connected using multi-point constraints and connector
elements. Many of the suspension and drivetrain components are
modeled as rigid bodies. The car, road surface, and wall are
placed into a single general contact domain and the car is
given an initial velocity of 25 mph.
E1
Input file name:
e1.inp
Increments:
62,934
Number of elements:
274,632
Inital stable time increment:
9.535E-07
Final kinetic energy:
2.100E+06
Memory requirement:
1200 MB
E2: Cell phone drop
This benchmark consists of a simplified model
of a cell phone impacting a fixed rigid floor. The cell phone
components are meshed using a variety of element types
including C3D8R, C3D10M, and S4R. The material behavior is
modeled using linear elasticity, isotropic hardening Mises
plasticity, and hyperelasticity. The components are assembled
using surface-based mesh ties and placed into a general
contact domain that also includes the floor. The initial
velocity and orientation of the cell phone is defined such
that a severe oblique impact occurs.
E2
Input file name:
e2.inp
Increments:
87,369
Number of elements:
45,785
Inital stable time increment:
3.431E-08
Final kinetic energy:
6.043E+02
Memory requirement:
300 MB
E3: Sheet forming
This benchmark consists of forming a sheet
metal part by the deep drawing process. The deformable sheet
metal blank is meshed with shell elements of type S4R and uses
an isotropic hardening Mises plasticity material model. The
tools are meshed using surface elements of type SFM3D4R which
are declared rigid. General contact is defined between the
blank and tools. The analysis sequence consists of two steps.
During the first step the blank is clamped between the binder
and die and then during the second step the punch is displaced
to form the part. Since the process is essentially
quasi-static the computations are performed over a
sufficiently long time period to render inertial effects
negligible. The performance of this analysis is a direct
measure of the performance of the three-dimensional general
contact algorithm.
E3
Input file name:
e3.inp
Increments:
31,177
Number of elements:
34,540 (deformable only)
Inital stable time increment:
7.151E-07
Final kinetic energy:
1.391E+03
Memory requirement:
550 MB
E4: Projectile penetration
This benchmark consists of a projectile
penetrating a steel plate at an oblique angle. Both the
projectile and plate are meshed using hexahedral elements of
type C3D8R and use a rate-dependent isotropic hardening Mises
plasticity material model with failure. The projectile and
plate are placed into a general contact domain with surface
erosion. The edges of the plate are held fixed and the initial
velocity of the projectile is specified so that the projectile
passes completely through the plate.
E4
Input file name:
e4.inp
Increments:
12,433
Number of elements:
237,100
Inital stable time increment:
4.957E-09
Final kinetic energy:
1.469E+04
Memory requirement:
1400 MB
E5: Blast loaded plate
This benchmark consists of a stiffened steel
plate subjected to a high intensity blast load. The plate is
meshed using shell elements of type S4R and uses an isotropic
hardening Mises plasticity material model. There is no
contact.
E5
Input file name:
e5.inp
Increments:
81,716
Number of elements:
50,000
Inital stable time increment:
6.122E-07
Final kinetic energy:
1.050E+01
Memory requirement:
150
MB
E6: Concentric spheres
This benchmark consists of a large number of
concentric spheres with clearance between each sphere. The
spheres are meshed using hexahedral elements of type C3D8R and
use an isotropic hardening Mises plasticity material model.
All of the spheres are placed into a single general contact
domain and the outer sphere is violently shaken which results
in complex contact interactions between the contained
spheres.
