This week I wanted to write a brief post regarding a very common problem that can be found when running and post-processing Finite Element models: the correct definition of contact algorithms.
During this week, I had a conversation with other engineers about some issues related to the TIED CONTACT definition. In these terms, any commercial FE package gives you the opportunity to define this type of contact in a relatively easy way: you select the nodes or surfaces (master and slave) and then the pre-processor shows some kind of symbol in order to highlight that the contact has been established. However, the symbols and the fact that you have followed the standard steps of the software do not mean that the parts are going to behave as expected.
I’ll give you an example. Two years ago, while I was still studying at Cranfield Univesity, we had quite a few problems when we tried to simulate a drop test of a pedestrian headform attached to a helmet. The aim of the test was to determine the acceleration that the headform suffered in order to assess the protection level of the helmet. During the experimental campaign, we attached the equipment to the helmet in a way that we were sure that certain areas were always in contact with each other. In other words, some parts of the helmet were “tied” to some areas of the headform during the whole test. The thing was that when we simulated the same conditions using LS-DYNA, the results from the analysis were not exactly the same as the experimental ones. It took us a while to figure out that the reason why the model was not behaving correctly was because some of the nodes were not in contact after all. Because of that, we looked into the best way to prevent this issue, which was not rocket science after all.
From my experience, the first thing to do is to define the contact following the standard method of your software. Then, before running the analysis, you should always check that contact that you’ve previously defined. How can you do that? Well, it depends on the FE package that you are using. For instance, if you are using LS-DYNA, its pre-processor (LS-PrePost) has an option called “Contact Check” that uses a colour code to show the contact pairs: green nodes are effectively in contact, whereas red ones are not. Easy, right? On the other hand, if you are an Abaqus user, it is not that straight forward. In that case, you have to write the input file. Then, you can open it in a text editor and, at the very beginning, you’ll see a line which starts with *Preprint. Along that line you should be able to find the option “Contact=No”. All you have to do is change it to “Yes”. By doing this, the programme will produce some additional text in the output files when you run the model. That extra text basically shows the id number of the nodes which are part of the contact pair and a word next to them, stating “OPEN” or “CLOSE”. If the nodes show “OPEN”, that means that they are not in contact.
The final thing to do is correct the contact in order to have all the desired nodes interacting with each other. How can we do that? It’s very easy. Going back to the definition of the contact you’ll find an option which is usually called “Tolerance”. By changing that value you will be telling the programme to modify the distance around the nodes in order to consider them in contact. In other words, you can have two instances which are not touching each other in the assembly, but if you specify a tolerance equal to the distance between them, the contact algorithm will effectively pair the nodes.
I know this post may have been a bit boring but I really hope that it will help some users to solve some of their problems! Sometimes, all you need is two nodes which are not behaving correctly to obtain wrong results or not even a result at all! I will try to keep identifying more common FE problems, so keep visiting the blog!