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.

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