Maybe you recognize this: you set up your model, start running the job, open the monitor window and ... it stays empty, longer than you would like. The simulation is taking longer than you hoped or expected and you wonder: "how can I do this faster (without significantly reducing the accuracy of the results)?" In this blog I'll discuss some ideas and experience we've had related to simulation speed.
1. Don't use more elements than necessary
One of the main factor contributing to the running speed is the number of degrees of freedom, with twice as many degrees of freedom leading to a more than twice as long simulation. A simulation with less elements of the same type will thus be faster.
For a symmetric problem, only half can be simulated. This should reduce simulation time with at least a factor two. With the visualization options in Abaqus it is possible to visualize the complete construct, while simulating only half. If an axisymmetric approach can be used, this will reduce simulation time even more, while still allowing visualization of the entire construct.
In some cases the geometry and the first loading step are axisymmetric, but a subsequent loading step isn't. An example is the pressurization of a simple tire, followed by in-use loading, when the tire stands on the ground. In such cases the first loading step can be simulated using axisymmetric elements. From the axisymmetric model, a 3D model can be generated. The load state in the axisymmetric model can be copied to the 3D model. Using this approach saves simulation time.
2. Ensure the scratch data fits in your system's RAM
Having many degrees of freedom becomes especially problematic if the scratch data of the analysis can no longer completely be kept in memory. The amount of memory needed to keep all scratch in memory is estimated when doing a data check and given in the .dat file, under "MEMORY TO MINIMIZE I/O". When Abaqus needs more memory than the amount of RAM available, virtual memory will be used: disk space is used as additional memory. Writing to and reading from disk requires additional time, thus reducing performance and increasing simulation time.
3. Don't allow a single element to ruin your simulation speed in Abaqus/Explicit
An explicit algorithm is conditionally stable. The time increment used must therefore be small enough to ensure stability. When a smaller time increment is used, more increments are needed to simulate the same amount of total time and the simulation takes longer.
The stable time increment is based on element density, size and stiffness. The stable time increment is reduced with a smaller density and size as well as with a larger stiffness.
In Abaqus/Explicit, the maximal stable time increment is calculated per element. The smallest value of all elements is then used for the analysis. This means that if all elements but one have a stable time increment of 1e-5 and the last element has a stable time increment of 1e-7, a time increment of 1e-7 will be used. The simulation will take 100 times longer due to this single element with a smaller stable time increment!
Because of this, it is important to know which elements are limiting the time increment and modify them if possible. The 'verify mesh' tool in the mesh module can highlight elements with a stable time increment less than a specified value. This helps determining where changes can have most impact. What the time increment is and which elements determines this is also written to the .msg file and visible from the job diagnostics.
Changing the mesh so that the size of these elements increases will reduce simulation time, especially if there are a few elements with a much smaller stable time increment than the rest.
4. Use scaling for quasi-static analyses in Abaqus/Explicit
In Explicit analyses, simulation time can be reduced if the total time to be simulated is reduced, or the stable time increment is increased. For quasi-static analyses, the total time simulated can sometimes be reduced by applying the load faster. This can not be done indefinitely: when the load is applied too fast, dynamic effects start playing a role and the solution is changed. When using rate-dependent properties these should also be scaled. In such a case it may be easier to increase the stable time increment.
The stable time increment can be increased by increasing the mass. This can be done manually, by specifying a larger density. Abaqus can also automatically increase density, to increase the stable time increment and make the simulation run faster. This is called mass scaling. It is available in the step editor for Explicit steps, under the 'mass scaling' tab. Because mass is added, inertial forces will be modified. So, as when the load is applied faster, care should be taken that inertial effects don't influence the solution; the kinetic energy should be small.
5. Use parallelization
One of the most effective ways to reduce running time, is to use parallel processing. In a perfectly parallelizing simulation, the simulation time is divided by the number of cores used. In practice this is never the case, because it takes some effort to divide the problem and distribute it over different cores. But, in some cases, you can get very close.
Parallelization can be switched on from the 'Edit Job' dialog box, in the 'Parallelization' tab. When working from the command line, add the option: cpus=N with N the number of cores to be used.
It is difficult, if not impossible, to determine how well a simulation will parallelize. However, there are some factors that are known to limit the possibilities of parallelization, such as:
- limited amount of degrees of freedom (DOF). The overhead for parallelization is relatively bigger when the number of DOF is smaller. We have even seen an example were running on more cores was actually slower then running on less cores. As a rule of thumb, there should be at least 5000 DOF per core.
- contact/constraints involving a large section of the model. If half of the model is included in a single constraint that can't be divided over cores, then the model will not scale properly when using more than 2 cores.
Running on multiple cores requires more tokens. How many you need can be calculated using our new token calculator. 5 tokens are needed for running on a single core. Up to 8 cores each additional core requires an additional token. For a perfectly scaling simulation, this means that by going from 5 to 6 tokens, the simulation time can be halved.
For Abaqus the use of hyperthreading is not recommended, because it does not speed up the simulation while more tokens are used. Thus, based on the computer, the maximal number of processors that is reasonable is the number of physical cores, not the number of virtual cores. Hyperthreading can be turned off from the BIOS.
If enough tokens and computer resources are present it can make sense to run the first part of an analysis on different numbers of cores, to see how well it scales and determine an optimum number of cores.
6. Pay attention to constraints
Even without limiting parallelization (see point 5), constraints can have a negative effect on simulation time in Abaqus/Explicit. For constraints such as TIE, COUPLING, MPC and CONNECTORS an implicit approach is used in Abaqus/Explicit. This can greatly reduce running speed, especially if many nodes are involved. We've seen an example of a simulation becoming more than 15 times faster by removing an MPC and changing it into contact with a rigid surface!
7. Regularly restart your system
I have noticed that on my (Windows) workstation, running time can be reduced when restarting the system in between running big analyses. I've seen a running time of about 40 and of about 20 hours for the same problem, running on all 16 cores in both cases. Though the restart may not be the only cause, it does seem to help. In another case we ran an analysis in about 6 minutes, restarted the system, ran the same analysis again and then it took around 4 minutes. Though not as impressive, there does seem to be an effect and simply restarting the system may already increase running speed.
Want more help with letting your Abaqus run faster?