Predicting material failure is always a challenge, especially when it comes to composites and advanced materials. There are plenty of theories that try to provide a numerical approach to solve this complex problem, such as Maximum Stress/Strain Theories, Hashin, Tsai-Hill or Tsai-Wu. Although all of them brought something valuable to the table, some of them don’t seem to be that precise when accurate results are needed. In these terms, Tsai-Wu is my least favourite criterion and I’ll explain the reasons for that.
First of all, Tsai-Wu is an interactive failure criterion for composite materials. This means that the theory takes into account the interaction of different stress components in order to predict failure. Basically, the criterion uses equation 1 (subjected to the condition given by equation 2) to calculate an index and, if its value is one, then it means the material is failing. Please note that i,j=1,2,…,6, where subindices 1 to 3 represent normal stress components and 4 to 6 are shear stress components. In the original publication, authors explain how the different coefficient can be determined through experimental tests (e.g. compression, tension, biaxial…). So far, so good.
If you are an advanced Abaqus user, I am sure you have heard a word which some people try to avoid at all costs: subroutines. Today, I write about them as well as about my recent experience coding one for my research.
First of all, lets start with the main question: what is a subroutine? It is a script that, when run in parallel with the Finite Element (FE) model, allows users to request features which are not defined by default in the commercial software Abaqus. This FE package recognises a lot of different types of subroutines for both implicit and explicit simulations, depending on the information that we want to include, recalculate, modify, request… In other words, subroutines are useful when we want something that is not already available within the software and we need it in order to produce acceptable results.
Consider, for instance, that we were trying to simulate the response of a certain material, but the material model which was available in Abaqus did not quite reproduce the correct behaviour. What could we do then? The first option would be to contact Dassault Systemes to ask if they had any kind of expansion (with its corresponding extra cost, not too many things are given for free these days I’m afraid); sometimes, since a lot of users request the same thing, it is the company itself the one that creates the official subroutine. This option would save time and effort, but it would also affect our wallet. The second option would be to create a new material model from scratch. How could we do that? Well, we would need to code a UMAT (implicit) or a VUMAT (explicit) subroutine. In order to do so, we would need to learn how to code in Fortran, which is the only language supported by Abaqus (I know, this is a bit of a pain since Fortran is basically obsolete, but hey! It’s always good to learn something new!). We would also need to install two compilers and link them to the FE package, which once again is not straight forward (don’t worry, I’ll try to write another post to explain this). Some people might say that giving up would be the third option, but to me that attitude would be unacceptable, so don’t you dare!Continue reading →
If you are a regular Abaqus user, I am sure that eventually you will need to run models for long periods of time. It can be quite annoying to go back to the office just to check if the simulation has finished to then find out that it is still running. For that reason, I’ve coded a simple python script that sends an automatic e-mail to the user once the simulation is completed or aborts due to errors.
While you run FE models that take a huge amount of computational time to finish, it is likely that you will be working on other things, such as experimental tests, reports, meetings and so on. Obviously, we want to check our results as soon as they are ready, but in order to do so we need to be checking our computer every now and then. This can be particularly annoying when you leave a simulation running for a few days and you are doing things out of the office. Hence you need to go and check if the model is done… and then you realise it’s still there, calculating more stresses and strains and that your trip to the office was a waste of time. To overcome this problem, I decided to create a python script to send a notification directly to my e-mail every time my analyses finish. I will try to explain you the basics so you can use this code on your computer.Continue reading →
Basically, when we want to determine the forces and displacements in a certain structure using Finite Element Analysis (FEA), what we are doing is creating a system of equations that relates the stiffness of the elements to the displacements and forces in each node. When we run a simulation, we do not see all the calculations. For that reason, today I want to illustrate a simple case that can be easily solved by hand applying that methodology.
Before getting started, just think of a spring. Everyone has come across the Hooke’s law at a certain point during school. It states that the force in the spring is proportional to a constant “k” multiplied by the variation in length of the spring. FEA follows the same principle, but in this case the “k” constant is the stiffness matrix and the variation in length is a vector of displacements and rotations, depending on the case.
Let’s study a simple static case. Our structure consists of two bar elements connected at a common node, where a load “P” is applied. The other two nodes have both horizontal and vertical displacements constrained (see the boundary conditions). For this particular case, the reactions in nodes 1 and 3 and the displacements of node 2 are requested. I have solved the problem by hand following a few steps that, based on my experience, can be generalised for more complex problems. Pretty much, the summary of the methodology is:Continue reading →
As I promised a few weeks ago, I’m back with a tutorial! In this occasion, a cantilever beam will be modelled in Abaqus/Standard. What is more, the importance of defining a good mesh (not only the element size matters!) will be illustrated with several examples.
So, first things first. A cantilever beam is a structure which has one of its ends fully constrained. This means that all degrees of freedom are restricted. An example is presented in the following figure:
A similar case as the one presented above will be modelled using the Finite Element package Abaqus/Standard. The structure can be created using different types of elements: beam, bar, solid or shell. I have decided to model it using shell elements, since it will allow me to show the influence of the element size and type in a very simple way.
In order to create the component we need to be in the Part module. We should select the 3D deformable shell(planar) option. Then we will be able to create the geometry. In this case a simple rectangle of 20mm x 100mm will be enough. Please bear in mind that Finite Element codes are unitless and all the parameters need to be defined in a consistent system of units. I have decided to use mm, GPa and kN.
New post about FEA! In this occasion, I bring you some theoretical background for two types of elements which are very useful for modelling certain structures: bars and beams.
Let’s start from the beginning. A bar is basically an element which can resist only axial loading. Therefore each of its nodes has one degree of freedom, i.e. a displacement along the longitudinal axis of the element. On the other hand, each node of a beam presents not only one but three degrees of freedom: displacement in the longitudinal axis, displacement in the transverse direction and rotation.
As you should already know, Finite Element Analysis requires the a stiffness matrix (K) so, in order to illustrate this, in this post I will show you how the K matrix can be derived for bar elements. Note that the process for obtaining the stiffness matrix of a beam element is similar but a bit more tedious.
Happy New Year everyone! After a well deserved Christmas break I’m back with some more engineering topics. In this occasion I want to introduce a new series of brief posts about Finite Element Analysis. The idea is to cover one topic for each letter of the alphabet (i.e. from A to Z). Let’s get started!
Motivated by the “A-Z Challenge” that I followed for the first time thanks to Dr David Jesson, the idea of doing something similar has been growing in my head for some time. However, in this case I won’t be writing a post every day but, hopefully, once a week a new one will be published.
I had some doubts about the topic, but after meeting some of the members of the Formula Student Team of the University of Seville (Spain), I thought it would be a great idea to do some kind of simple Finite Element guide. In particular, this guide will be focused on the commercial package Abaqus. Some of you might be wondering why I’ve chosen this particular software, and the reason is pretty obvious: it is one of the most used FE packages in industry and loads of students struggle to understand how it works, especially if their first experience with FEA involved Ansys. Don’t get me wrong, I started using Ansys as well and I don’t want to give the impression that I have a problem with it. The thing is though, that a lot of people tend to learn how to model things in Ansys by heart and because of that, they won’t be able to reproduce the same models in other packages.
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.Continue reading →
One of the dangers of FEA is that it provides results, even if they are wrong. Hence it is the engineer’s responsibility to critically analyse and validate them. In these terms, one of the most common rookie mistakes is “hourglass”. If you want to learn what it is and how to correct it, this is your place.
To begin with, let me introduce two different concepts: underintegrated elements and fully integrated ones. Underintegrated elements are only evaluated at one single integration point, whereas fully integrated ones have more than one. In order to illustrate this idea, Figure 1 is introduced.
Figure 1 (a) Underintegrated element; (b) Fully integrated element
The main idea of this post is to provide an overview of the outline of a Finite Element Analysis for people who are not familiar with this engineering tool.
The starting point for every Finite Element Analysis is a real problem which has to be solved. For that purpose we have to create an idealised structure and, from that idealisation, we should be able to design a discrete model. Hence, using the Finite Element Method, a discrete solutions can be obtained for that model.