Abaqus Release 6.10 Performance Data

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 Abaqus releases.

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).

Contents

Organization of the Benchmarks  Hardware Categories Abaqus Job Categories Presentation of Benchmark Data Abaqus/Standard Benchmark Problems Abaqus/Explicit Benchmark Problems Workstation Benchmark Data Server Benchmark Data Abaqus/Standard Server Benchmark Data Abaqus/Explicit Server Benchmark Data Organization of the Benchmarks 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

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: Plate with gravity load 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 Disk space requirement: 2 GB Benchmarks with problem S1 : " . $ref . " "; } } else echo "No benchmarks found for problem S1"; ?> 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. A single version of this benchmark is provided at this time. In earlier releases a second version using the Abaqus iterative solver was provided, but that version has been deprecated. S2a: Direct solver version 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 Disk space requirement: 4.55 GB Benchmarks with problem S2 : " . $ref . " "; } } else echo "No benchmarks found for problem S2"; ?> 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 S3b: 1,100,000 DOF Lanczos eigensolver version S3c: 1,100,000 DOF AMS eigensolver version 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 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 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 Disk space requirement: 19.3 GB Benchmarks with problem S3 : " . $ref . " "; } } else echo "No benchmarks found for problem S3"; ?> 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 version using a smaller model (700,000 DOF) with a low iteration count, a version using a larger model (5,000,000 DOF) model with a low iteration count, and a version using the smaller model but with a higher iteration count. These three models are used to demonstrate that as a general rule parallel scaling in Abaqus/Standard improves as either the model size or the number of iterations increases. S4a: 700,000 DOF, 5 iteration version S4b: 5,000,000 DOF, 5 iteration version S4d: 700,000 DOF, 27 iteration version S4a: 700,000 DOF, 5 iteration 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 Disk space requirement: 3 GB S4b: 5,000,000 DOF 5 iteration 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 Disk space requirement: 23 GB S4d: 700,000 DOF, 27 iteration version Input file name: s4c.inp Increments: 20 Iterations: 27 Degrees of freedom: 720,059 Floating point operations: 5.77E+11 Minimum memory requirement: 895 MB Disk space requirement: 3.3 GB Benchmarks with problem S4 : " . $ref . " "; } } else echo "No benchmarks found for problem S4"; ?> 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 : Stent expansion 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 Disk space requirement: NA Benchmarks with problem S5 : " . $ref . " "; } } else echo "No benchmarks found for problem S5"; ?> 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 : Tire footprint S6 Input file name: s6.inp Increments: 41 Iterations: 177 Degrees of freedom: 729,264 Floating point operations: NA Minimum memory requirement: 397 MB Disk space requirement: NA Benchmarks with problem S6 : " . $ref . " "; } } else echo "No benchmarks found for problem S6"; ?>

Abaqus/Explicit Benchmark Problems

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: Car crash 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 Benchmarks with problem E1 : " . $ref . " "; } } else echo "No benchmarks found for problem E1"; ?> 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: Cell phone drop 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 Benchmarks with problem E2 : " . $ref . " "; } } else echo "No benchmarks found for problem E2"; ?> 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: Sheet forming 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 Benchmarks with problem E3 : " . $ref . " "; } } else echo "No benchmarks found for problem E3"; ?> 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: Projectile penetration 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 Benchmarks with problem E4 : " . $ref . " "; } } else echo "No benchmarks found for problem E4"; ?> 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: Blast loaded plate 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 Benchmarks with problem E5 : " . $ref . " "; } } else echo "No benchmarks found for problem E5"; ?> 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. E6: Concentric spheres E6 Input file name: e6.inp Increments: 23,291 Number of elements: 244,124 Inital stable time increment: 2.116E-07 Final kinetic energy: 2.034E+06 Memory requirement: 1000 MB Benchmarks with problem E6 : " . $ref . " "; } } else echo "No benchmarks found for problem E6"; ?>

Linear Benchmark Data

Workstation Benchmark Data

Server Benchmark Data

Abaqus/Explicit Server Benchmark Data

Abaqus/Standard Server Benchmark Data