At Fidelis, we're passionate about finite element analysis (FEA) for simulation. As analysts ourselves, we're all too familiar with the despair and frustration that comes with developing ~what you think~ is a robust finite element model, only for it to self-terminate with errors. "What is going on?", "Where did I go wrong?", "Does this computer not understand what I'm trying to do here?" These are questions we've all asked... even if it is under our breath.
This series of blogs is aimed at helping you, the analysts, to solve all the typical - and not so typical - analysis errors that we've seen over the years. Of course, there may be some that we miss, but hopefully we can set you on the right track to first diagnosing and then fixing these issues with your models.
'Debugging' is a word that is often used to describe the process of finding and fixing modeling errors. This post will concentrate on the steps you should go through to first find and then diagnose the problem. We're going to focus on Simulia's Abaqus solver, but the methods we use and the problems we highlight will be relevant to most commercial FEA packages (although you might have to work a little harder to find the equivalent information). Then, week by week, we'll add to the knowledge base of standalone articles that tackle specific errors and issues and combine them in a list at the end of this post.
So lets get started... where do we begin?
1. The STA file
The .sta or ‘status’ file can be a good place to start when trying to debug an Abaqus FEA model. It shows very basic information regarding what the computer is trying to do at all stages of the analysis.
In this file, you can see the size of the increment that the solver is working on and how 'difficult' it is finding it to solve. An increment is the 'chunk' of the step that the model is trying to resolve. Often, when complex or non-linear events are to be simulated, the step needs to be broken down into many 'bite-sized' increments that the computer can deal with and converge upon static equilibrium. The more attempts (or iterations) made, the more of a challenge it was to solve that increment and this might let you start to see where something is going awry.
We also recommend you assess the size of the increment currently being processed and compare it to the size of all increments that came before it. Sometimes a model will be solving along nicely and then it will come to an increment that needs to be 'cut back'. This means that a solution to the current increment could not be found and the solver will try to cut down the size of the ‘chunk’ to help ease convergence. Often, cutbacks are a completely normal part of a complicated analysis and there is nothing to worry about. However, if the solution is cutting back unexpectedly, interrogation of this file can let you know, at a glance, the stage of the analysis that the problems occurred.
2. The DAT file
The .dat or ‘data’ file is typically most valuable when trying to diagnose a bug that prevents an Abaqus FEA model from starting. In here, you’ll find all the ‘warnings’ and ‘errors’ that the solver has spit out during the 'pre-processing' phase of the analysis.
Sometimes, you’ll find that the model run will not even begin. If this is the case, the cause will always be found in the dat file under the card ‘***ERROR:’. Often the cause of the failure will be obvious, like when you have one slave node that is being controlled by two masters. The solver will not even attempt to begin – you are breaking the rules. The dat file will tell you, not only that this is the problem, but also the nodes that are causing it, which really helps when you go to debug.
3. The MSG file
The .msg or ‘message’ file offers information regarding the actual running of the FEA model. It contains all the data generated during each attempt to solve an increment - iteration-by-iteration.
An iteration is an ‘attempt’ to find an equilibrium solution to an increment when solving with any implicit method. With every iteration, the solution should be getting closer to equilibrium, but that’s not always the case. This would be known as a diverging (rather than converging) iteration and is essentially the root of all problems we run into during an analysis.
Once the model gets started, some warnings or errors might become important mid-solution. For example, this is the case when strain in an element becomes overly high and Abaqus is ‘***WARNING:’ you that it might be a problem. Another thing commonly diagnosed using the msg file is ‘rigid body motion’ in the model - the solver cannot converge on a stable equilibrium, because there isn’t one. Again, the msg file does its best to let you know what’s happening. In these cases it can be a little more cryptic, but that’s what our series of blogs is all about.
We can also probe the individual aspects of the solution to find the largest force and moment residuals and displacement and rotation corrections - and at which nodes they occur. On its own, this is not terribly useful, but, when combined with the information extracted from the other sources already discussed in this post, it can be invaluable when diagnosing and debugging a finite element model.
4. Check the ODB
The .odb or ‘output database’ is where the meat of the results are stored. Our final recommendation is less ‘scientific’ than those examined above, but, often, just as effective.
Sometimes, and this only works if the simulation has actually started and some results have been obtained, you can see exactly what the problem with your model is, simply by viewing the odb. In cases where boundary conditions are not applied correctly or excessive deformation is occurring where it shouldn’t be, you can see it in the visualization. This can be extremely helpful in debugging the model because not only do you know which region of the model is the problem, but you can more easily understand why it matters – you don’t have to visualize what’s happening in your head.
Another way the odb can help, even when no increments have been run, is through the ‘warning’ and ‘error’ node and element sets that Abaqus creates to try to help you debug. These can be found in the results tree (under node and element sets) and can be highlighted to show exactly where in the model the problem area lies. They are even named so you can understand what the issue is e.g. WarnNodeBCIncorrectDOF.
It should be noted here too that, when using Abaqus CAE, the tools>job-diagnostics will offer much of the important information contained within the standalone files previously discussed in this post. However, it should not be assumed that everything needed to diagnose an FEA model can be found here. At Fidelis, we always recommend that you interrogate the diagnostic files directly. They can usually be found in the directory from which the Abaqus job was executed.
Final Thoughts
So now we know where to look to start the debugging process, follow us as we build a knowledge base of answers to the specific errors and issues that you've successfully diagnosed. If you have any specific questions that you'd like the Fidelis team to answer, put them in the comments and we'll do our best to get to them as soon as we can.
And if you're still struggling, feel free to reach out to us directly. Whether you need us to take over the project you're stuck with, or just aid you understand where you're going wrong, we're here to help!