This installment of the “Debugging 101” series focuses on the final, and perhaps most important, file when it comes to understanding exactly what Abaqus is doing – the .msg or message file. We’ve already been through the typical things you should look for when debugging an Abaqus model, as well as the ins and outs of the status and data files, so if you’ve not read those posts yet, feel free to check them out. They provide some background information that might be useful when it comes to understanding the message file.
This post will walk you through everything that you will see in a typical Abaqus message file. Of course, there are many different issues that can be diagnosed within this file, and we don’t have the word count to go through them all in this post, so please look out for our more specific debugging tips, released weekly at FidelisFEA.com/blog.
The purpose of the message or .msg file is to inform us as to what is happening currently in our FEA job. We’ve checked all the inputs in the data file and now our job is running, meaning you’ll see the executable change from pre.exe to standard.exe (for an implicit analysis). Detailed information from each iteration of every increment is documented here in real time, and we can use this information to our advantage.
Step Control Summary
Firstly, we’ll see all of the ‘rules’ for the step printed at the top of the message file for step 1. These include some of the important definitions we’ve discussed before, such as the initial increment size, total time period of the step, maximum allowable increment size and minimum allowable increment size. However, there are many more parameters that the analysis needs to adhere to, known as convergence controls. Notably, we can see the criterion for the residual forces and moments that Abaqus has to achieve in each increment, before static equilibrium can be assumed and it is allowed to move onto the next. As well as these, severe discontinuity iterations, that deal with things like contact and slipping, also need parameters to work within. We could (and will) write a whole blog post on the setup of these parameters and why you might want to edit them, but for now, let’s just accept that these are Abaqus standard and note them for reference when we’re debugging. Above is a table taken from an example message file that shows Abaqus default values for some of the important convergence parameters relating to force equilibrium (values not absolute, but are maximum allowable ratios relating to time averaged forces and total displacements). You will also find tables like this for moments and, in thermal analyses, temperatures and heat flux.
Once we have either a successful (converged) or failed (diverged) increment, it is also important that rules are defined for the change in increment size as a result. This allows for close control of the efficiency of the analysis. Cut-backs that are too large result in unnecessary increments while overly aggressive increase factors can result in unnecessary cut-backs. Again, there are Abaqus defaults for ‘Incrementation Control Parameters’. Unless you are an expert user, its probably best to leave these as they are, but it is useful to take note of them so you have a detailed understanding of exactly the route your analysis will take to converge.
As with the .dat file, we also get a detailed breakdown of the parallelization of the job run as well as characteristic element size, type of non-linearity included, GPU acceleration enablement and the overall size of the model to be solved.
Detailed Iteration Data
This is where we really get to the most useful part of the message file. Abaqus prints the convergence checks for each and every iteration attempted during the analysis. These include the largest residual forces and moments, average volumetric fluxes as well as displacements and displacement corrections when we’re performing an implicit structural analysis. For thermal analyses, the data comprises of largest residual heat flux and largest temperature increments and corrections. We then get a report as to whether each of the maximums qualify as ‘equilibrium’ or not within the framework of the analysis.
Debugging Using the Message File
So, now we know the general layout of the message file, how can the information be useful when struggling with convergence? Well, firstly, it’s always good to know where the model is seeing the largest residual forces and moments, as well as the largest corrections to displacement and rotation. The size of these values - given that we already know the convergence criteria - and the node and degree of freedom (DOF) let us dial in on the location and severity of the convergence issue. However, don’t be too worried if these numbers look very high at the beginning of an increment. Remember that the solver is iterating towards an equilibrium solution using the Newton-Raphson method, so as long as these values are trending downward with each iteration, we are converging upon an acceptable (not perfect) solution.
If these values are increasing with each attempt to solve, then the solution is ‘diverging’, which means it is not likely to be solvable. There are many reasons for divergence of a solution, from rigid body motion, where there is little or no constraint on one or more of the parts of the model, to excessive plastic strain, where a region is deforming so much that elements become too misshapen and resistance to deformation is zero. When these types of issues occur, ‘warnings’ and ‘errors’ will be printed within the message file with the aim of pointing the user toward potential issues, similar to those in the data file that we discussed in an earlier post. It is the ability to combine the data provided to you in all of these files that will eventually lead you to becoming an expert debugger, but, based on the information provided in this post, you’ll at least have a starting point to find where your problems lie within the model.
Analysis Summary
It is also worth noting the analysis summary that is provided in the message file upon completion. This allows the user to quickly and easily review the number of increments that were needed to run the analysis, as well as other useful information like the number of cut-backs that were required, the total number of iterations and a record of the number of ‘warning’ and ‘error’ messages that occurred throughout the analysis.
Final Thoughts
It might seem overwhelming that there are so many potential issues with your model, but when you pair the error and warning messages with the locations and DOF data, you’ll be well on your way to debugging models like a pro. And, of course, the more time you spend effectively debugging models, the more experience you’ll gain and the better your initial model building will become – you’ll stop making the mistakes in the first place.
Whether you’re an experienced Abaqus user or a complete beginner, Fidelis can help you get the most out of the software with bespoke support and fully integrated simulation solutions. Call or email us today to learn more about our offerings.