It’s time for the second part of the #FEAchecklist! Last time we were checking stuff before starting an analysis. Now, let’s wonder what to check if you see analysis errors when your analysis fails to run. I can honestly say I’m kind of an expert here… I’m pretty certain I’ve made most of the possible analysis errors (and several times each!) so far! This also means I’ve seen most of the error messages out there : )
Sadly this won’t be a complete list, as such would take ages to write. I will just point out the most popular errors here, aided by the list Asia made, and some of my own ideas.
You can read that, it won’t hurt
Before we start with the most common problems I think it’s fair to start with something that didn’t occur for me for a long time. I’ve treated all analysis error messages like a sentence – you know my solver told me I failed! But, you can treat them as messengers instead! Your solver tries to help you – something didn’t work and it’s doing it’s best to tell you what!
After all, someone did wrote the solver you are using, and even for themselves, they made notes inside. Just in case they forgot about something later (not to mention helping others).
Sure, some solvers were made a long time ago, and some notes may be hard to get (Nastran still measures system memory in “words” rather than Megabytes!). However, those error messages are the only thing you got!
Usually, you can see error messages in the analysis window. Those are the “shortened version” of whatever solver spilled. Femap has a way of showing those I really dislike – see above. If simply fragments the analysis file by keyword – reading this is rather hard!
Hopefully, you can track a text file your solver leaves behind. In NX Nastran that would be a [name of your analysis].f06 file (.log and .fo4 also contain some useful data). Whenever you get an error message try to take a look at the end of those files, and scroll up until you find something interesting! I usually use a simple notepad to do this, as it is quite comfortable for that 🙂 The same error message from above looks like this:
I know I could find this text in one of the “tabs” in the Femap window. However, text file also has a “structure” as it was made by a human, so that a human can read it. It has a certain “format”. When you get used to it – it’s easy to find what you are looking for.
Oh, look! It seems I forgot to support my model or did it poorly. “User action” suggests that I should either support my model better (solver suspects that it’s a mechanism) or that I can use “BAILOUT” and try to see what is moving. In order to learn more about this PARM,BAILOUT I would have to search for this term in “solver dictionary”. There is always a document (usually 2000+ pages) containing all solver keywords. Find it! If you know the keyword, it’s easy to find it. Then all you need is to read what and how it’s doing… and implement it if needed!
See! Solver ties its best to help us out in this dire situation. Analysis errors are a problem for the solver as well. It tries to help out as much as it can : )
But lets us take a look at more common problems as well!
Assuming I didn’t read the warning message there is one thing I will always check first!
- “Coincident nodes” check: Sometimes when you mesh a model “part by part”, nodes on the same line from various plates do not “merge” by themselves. This means that mesh looks awesome, but there are actually 2 nodes in each place. In short, it means that even as it looks perfect, the model isn’t actually one piece, but several! You can check that by displaying “free edges” of the mesh or searching for coincident nodes. There should be an automatic check that does such things : )
- Local mechanism: This is a bit tricky one. You can have a really well-supported structure. But if you have 2 parts connected by 3 hinges in a row, for instance, this is the mechanism. Thinking if you have such a place in your model can save you a lot of trouble! There are of course many “unstable” connections you can think about. But it’s not a place to describe them all – I will make an article about it someday : )
B. Boundary conditions
Yea, those are important! I think that boundary conditions are one of (if not “the”) most important sources of critical errors. Sadly’ only part of those result in error messages. Most will compute and show outcomes… that makes no sense since the model is wrongly supported! Be very careful here!
- Is the model well supported? Try to figure out if your support system actually makes the model stable. If you are unsure reach the error message – it should be of some help! You can also try to make only linear analysis or LBA (linear buckling). If you manage to compute those, they should show you where the deformations are too big. However, there is a chance they won’t. If you don’t know in a worst case scenario you can try with trial and error to see if adding supports here and there helps.
- Do you have point supports? I mean literally, a support in one node somewhere? If this is in beam model, that’s fine. Otherwise, it can show you a lot of errors due to mesh distortion, to big stress rations, too high strain etc. Simply put, point supports and point loads (as point connection between the beam and shell elements) put a lot of “numerical hurt” at the elements nearby. There are internal measures of such “numerical hurt”. If solver thinks elements can’t take any more – it will throw an error at you!
Apart from the point loads listed above, there is one additional check you need to make in nonlinear analysis!
- Are loads dependent on time? This is not an “analysis” question, but a purely technical one. Let’s assume you want to use a static analysis (so time is clearly not a factor in anything). In NX Nastran there is a nonlinear solver (SOL 106). It will divide the load as it sees fit (or as you ask!) and does the analysis. However, in the same NX Nastran, there is an “advanced nonlinear solver” (SOL 601). If you want to run a nonlinear static there, you need to implement “time” into the load. A simple linear “time = 0 means load = 0 and time =1 means load =1” will suffice. It’s just that Adina uses “dummy time” to do iterations. If there is no “time” provided, it doesn’t know what to do! This has nothing to do with dynamics! It’s just how iteration system was built!
There are so many wonderful things that can go wrong here : ) After all, analysis can easily cause analysis errors!
- No convergence error: This is pure magic. It’s just that solver just told you… sorry, something went wrong! This can be because you’ve added too much load and capacity is too small (apart from arc length convergence will be very difficult then!). Or maybe the load increment is too high. Or something else went wrong. Oftentimes, this is connected with “analysis steering“
- Analysis definition: Always check that. Maybe you misclicked somewhere (I know I did on several occasions). Or you forgot to define which loads or boundary conditions analysis needs to take into account. It’s always a good idea to look in the analysis settings!
Yea… that! Well contact can definitely be a source of all different error messages : )
Let’s try to deal with some of them, shall we?
- Regions/Areas: Contact is always assigned to regions or areas. Are the correct places picked? If so, do the normals of those regions are in the correct direction? Usually, when you set contact you define whether it should happen on the “positive” or “negative” surface of anything. It’s the surface normal that defines what does that mean. If you misjudged the directions switching things up will help. I know that from time to time I actually do contact with trial and error when I’m too lazy to check normal directions (never liked doing that for some reason :P).
- Offsets: Often, especially in shell models, contact will happen at a certain distance from the shell. This takes its thickness you haven’t modeled into account. Maybe the offsets are wrongly set up? This way instead of “being initially in contact” your model isn’t actually touching at all (or one part is “penetrating” other)? This would cause a lot of convergence problems if you weren’t ready for it.
- Initial penetration: Sometimes, it would happen that parts that should be in contact penetrate each other at the start (i.e. due to wrong offsets!). In such case, if you clicked “remove initial penetration” this may cause a lot of stresses in your model that is “weird”. This is because before analysis solver will push the nodes of the penetrating elements outside. If parts are rigid, it will produce very high stress!
- Does your solver support contact: This is something I have issues with. I’m used to SOL 601 in NX Nastran (this would be “advanced nonlinear solver”). However, from time to time I use “normal nonlinear solver” (SOL 106). In the latter, I can’t use contact, as it doesn’t support this! This means That if I try to do it, I get some error messages!
Last few thoughts!
You’ve made it! This is the list of the most common things I would search for. If you haven’t found your error here no worries. Just read the solver message and try to find out what is going on. You can also google the error message text! You will find your answer this way from time to time!
I hope you’ve enjoyed this article. If so, please share it with friends and colleagues – this will be a great help!
Want to learn more about FEA?
That’s great! Don’t miss my free FEA course! Get it by subscribing below: