This post is part of our wider series of blogs that are focused on helping you, the analysts, to better understand and debug your Abaqus finite element (FEA) models. As you may have read in our previous post, there are a number of routes you can take when trying to find the root cause of a failed Abaqus run. We gave you a snippet of information regarding the .sta or ‘status’ file, but here we’ll delve a little deeper into what the data can tell us about our run and how you might tweak the analysis settings to help it solve.
Steps
Typically, every event that is to be simulated throughout the course of an analysis is done so in it’s own unique ‘step’. Procedure options can include changes in load, boundary conditions, temperature and a host of other things that Abaqus can deal with. An example of this might be an axle assembly where step 1) includes the pre-loading of the bolts, then 2) a torsional load is applied to the pinion and 3) a pothole type impact load is applied to the whole system. In this case, three steps are included in the analysis.
In the example pictured above, we are looking at the beginning of ‘Step 1’ (red column) of what appears to be a slowly converging Abaqus solve. Why? Look at the increment data…
Increments
An increment is the ‘chunk’ of the step that the computer is attempting to solve for static equilibrium. In the case above, we are looking at the first six increments (red column) of this analysis. For simple analyses, such as small, fully linear, models, it is common for Abaqus to solve the whole step in a single increment. However, where complex loading, contact, material non-linearity, geometric non-linearity or other significant discontinuities exist within the step, it needs to be broken down into more manageable, bite-sized pieces so that the nonlinear solution path can be followed. As a default, Abaqus will try to solve the entire step in one go and then, as necessary, it will ‘cut back’ the size of the first increment until it finds a solution that is acceptable. It then proceeds through the increments until the whole step has been resolved, increasing attempted increment size as it goes. Monitoring this file can help you to figure out how long your job might take and where the cutbacks, if there are any, occur. This might assist you in understanding what phase of the step Abaqus is struggling with – did something just move in or out of contact? Did some of the material just move past its yield point and become plastic?
Note in the example above that the user has set the first increment to be 0.001 or 0.1% of the total step size (blue column). This can be controlled by manually editing the input (.inp) file, or using the pre-processing tool of choice, and will be discussed in more detail later in the post. We can see that the second, third, fourth, fifth and sixth increments of this run all experienced cutbacks because they were too large for the computer to deal with. So, if the blue column is the current increment size, what are the others telling us? Well, the data in the green column gives us a running total of all the increments that have been solved so far in the active step, providing a direct indication of the portion of the step that has been successfully completed. The orange column is similar but combines the active step with all steps before to provide us with the total time for the whole analysis. For example, if the user was on step 3, the first line in the orange column would read 2.00100. Bringing us finally to iterations…
Iterations
The iterations are the attempts that the solver is making to find an equilibrium solution for a given increment when utilizing an implicit method. If the model is not in equilibrium at the end of an iteration, Abaqus will run another one. With every iteration the solver tries, the solution should be ‘converging’ upon static equilibrium. If this is not the case then the results are diverging and a solution cannot be found, at least for an increment of the current size.
When this is the case, Abaqus will reduce the increment size and try again. You can see in the red column that some of the increments in this analysis have had to be cut back. This is signified by a ‘U’ next to the attempt number, followed by another attempt using a smaller increment. The degree to which the size of the next increment has been cut back is evidenced in the purple column, where, in the case of the second increment, the size was reduced from 0.00100 (0.1% of the step) to 0.000750 (or 0.075%). After cutback, the smaller increment was successfully resolved and the analysis moved on to the next increment. By default, Abaqus will only cut back a given increment five times, and if a solution still cannot be found, the analysis will abort with the error ‘Too many attempts made for this increment’.
Iterations (blue column) can be separated into two distinct types. ‘Equilibrium iterations’ (green column) are those in which the solution varies smoothly and ‘severe discontinuity iterations’ (orange column) are seen where abrupt changes in stiffness occur. Typically, parts moving into or out of contact with each other cause severe discontinuities and this information can be useful when actively debugging a model using the status file. Stick-to-slip and slip-to-stick transitions are another common cause that you should watch out for. Of course, you can interrogate all of this information in much greater detail in the message (.msg) file.
Controlling Increment Size in Your Steps
Assuming you’ve separated the steps of the analysis out in a sensible manner, we’ll go straight into the controlling of increment size for each step. As previously mentioned, Abaqus assumes default values to control total step time and increment size when not otherwise specified by the analyst. However, it is often beneficial to manually adjust these parameters to improve the efficiency of the solve. Of course, Abaqus allows for much closer control over the analysis than described here, but that’s a post all of its own.
Using the input (.inp) file, a static step is defined by:
*STEP
*STATIC
And then the data line underneath ‘*STATIC’, separated by commas, are the following parameters:
1. Initial time increment – This defines the size of the first increment that Abaqus nwill attempt to solve. If not specified, Abaqus assumes a default value of 1.
2. Time period of the step – This defines the total “time” of the Step being solved and is almost always set to a value of 1 (though any value is allowable).
3. Minimum time increment allowed – This parameter defines the minimum increment of time allowed in the analysis. If the increment required is smaller than this, the solve will error out. Default is 0.00005.
4. Maximum time increment allowed – This is the largest allowable increment size, which has no upper limit as a default. It can be set to any value smaller than the total time period of the step
You can also do all of this in Abaqus/CAE by opening the ’Incrementation’ tab in the ‘Edit Step’ dialogue box.
Final Thoughts
So now we can efficiently interrogate an Abaqus status (.sta) file and understand some basic methods in which we can control the analysis. Because the status file provides high-level information regarding the progression of an analysis, it should generally be regarded as the first port of call when trying to debug an analysis. By interrogating the increment size and the types of iterations being solved (equilibrium vs. discontinuity), it can often help identify when your solution begins diverging and what the high-level cause can be attributed to (e.g. discontinuity iterations often suggest issues with contact convergence).
Of course, usually, if your analysis has finished without issue, then it is tempting just to be satisfied and move on. However, it might still be useful to check the status file and assess how the job went about solving, especially if you have similar jobs or iterations of the same job to run in the future. Is there a certain increment size that always causes a cutback? Set the maximum increment size to be below that next time and save the time taken attempting, ultimately, unsuccessful increments. Does the first increment see a lot of cutbacks before finally resolving (often the case with contact initiating)? Reduce the initial time increment to save those wasted attempts.
Knowing where to look and taking appropriate action to improve your models will, ultimately, make you a better and more efficient analyst. And if you’re still struggling, why not get in touch with Fidelis and let us help. Whether you just need some help getting started, or you’d rather outsource the whole project, we’re here to support all of your simulation needs.
