What are Nodes and Elements in Finite Element Analysis?

Nodes and Elements are the very backbones of Finite Element Analysis. You will use them in every analysis you will perform in FEA, so learning about them seems like a good idea! So, what are Nodes and Elements in Finite Element Analysis?

In FEA, you divide your model into small pieces. Those are called Finite Elements (FE). Those Elements connect all characteristic points (called Nodes) that lie on their circumference. This “connection” is a set of equations called shape functions.

Each FE has its own set of shape functions, that connect all of the Nodes of that Element). Adjacent Elements share common Nodes (the ones on the shared edge). This means that shape functions of all the Elements in the model are “tied” thanks to those common nodes.

Seems complicated? No worries – I will make it easy for you in just a second – just read on!

Finite Elements and their use

First of all, let’s deal with the Elements. In general, there are a lot of Finite Element types. But in such an overall post let’s just divide them into 1D elements (I will call beams), 2D elements (I will reference them as shells) and 3D elements (let’s call them solid).

The 1D element is just a line connecting two nodes.

2D elements are usually triangular (TRI) and Quadrilateral (QUAD) in shape. This means that the most popular are:

3D solid elements can be based on triangles and quads as well, those will produce the epitome of Finite Elements – TET and HEX elements:

There are of course other types, like Wedges. Also, elements can be of higher order, which simply means they will have more nodes than those you can see above. But all in all, those are the “basic” types of elements. Since we have the “pictures” behind us, let’s go to the “shocking” news!

Elements do not exist!

This is always the “fun” part of explaining this. I know that when you mesh your model you can see the Elements on your screen. You know something like this:

But, this doesn’t change a fact, that they aren’t real (in the most part). It’s easy to imagine that you cut your model into small pieces, and then do something with each piece separately. But this is not how the solver works. You see, the “real thing” are Nodes!

Did you notice that each element pictured in the previous part had a distinctive “dot” in each corner of its shape? That “dot” is a Node. Each “corner” of the Finite Element will have a Node! But as I mentioned before, some “higher order” Elements can actually have more Nodes that only the ones in the corners… this is irrelevant, however, in this explanation.

So picture this: instead of “chopping” your model into small pieces what you are actually doing is select important points (Nodes). Since “points” are only a set of coordinates you couldn’t really use them to calculate anything, could you?

This is why you want to connect those Nodes with “springs”. You know – if you put a plate under tension the Nodes in the plate will get further and further apart the more you pull right?

Of course, in the same plate under compression, the Nodes would get closer and closer. But it’s not for “free”. You need to apply a certain force to shorten or elongate the plate… because it resists the compression/tension.

So imagine we put several nodes at the plate, and then connect them with springs. Those springs will then elongate when pulled, and shorten when pressed… just like a “real plate”!

Looks reasonable right?

The art of the spring

It would be great if you could just connect the nodes in an orthogonal network like that, but we all know it’s a bit more complicated right? The simplest question would be: “what about shear?”. Clearly, the plate resists shear, while our “spring set” doesn’t. Simply put it will behave like this, and since neither spring got longer or shorter, there was no resistance:

Let’s add diagonal springs as well in this case. This will make our “spring system” behave a bit better:

As you can see, when the shear deformation happens, the diagonal springs get longer/shorter. You need to use “force” to elongate/shorten a spring, so our model “resists” the shear deformation this way. To be completely honest, it’s even a bit more complicated than that, but I would say that the spring simplification is a neat one. Even if this is not perfectly correct, it’s a great way to visualize how it works!

So the question is: what does it means, that springs are connecting the Nodes? Well, let’s use a very simplified explanation (as always!). This basically means that there is an equation, that tells you how much Nodes on the ends of the spring move in relation to each other when you apply a force. You can derive the spring properties from material properties, plate thickness etc. In other words, this is “mathematically doable”.

Of course, everything depends on everything else right? Imagine such a system:

Horizontal springs carry the horizontal force of course, but diagonals do that as well! This means that those “spring equations” governing the relative movement of nodes against each other are “coupled”. Also, note that when diagonal springs get longer they also “produce” a resultant that will shorten the vertical springs of our system… which really nicely fit into the Hooke’s law!

Springs and Elements

We already discussed, that “spring equations” are “coupled”. You can’t simply say that a single “spring equation” describes the force/displacement relation between 2 nodes. Take a look at this drawing:

It’s obvious that when Node A and Node B “move apart” due to the load, the green spring will expand. Sadly, the red springs will expand as well. This is why the equations are “coupled”. It’s never just one spring reacting to any given deformation. It’s always a “set of springs”.

If that is the case, we should think what are we willing to “couple” in one set of equations? Doing “everything at once” would be pretty intensive when it comes to computing, so let’s limit ourselves to 4 nodes coupled together! In 2D that would be a “QUAD4” element – the most iconic FEA element I think! Thanks to this simplification we only have a few nodes and a couple of equations to worry about in one “set”. This will be easily solvable “mathematically speaking”.

Basically, we just say: look those 4 Nodes are connected together with springs, and we will couple those “spring equations” together. This is what the “shape functions” really are – those “coupled spring equations” in one Finite Element! Of course, drawing all those springs in our CAE environment would be pretty problematic (and a bit inaccurate). So instead we will draw a quadrilateral shape that will show our 4 nodes in the corners – it’s a “nicer representation”, and it’s also a bit more accurate since springs are just a simplification. This way we can clearly see which 4 Nodes are connected together with our “shape functions” (or “coupled spring equations” if you prefer).

The last big “if”!

This sounds so nice and all, but of course, this is not the end of the story. There is one last thing we are missing: We have far more than a single Element, and they share Nodes!

Of course, each Element has “coupled spring equations”, and different Elements can share Nodes. This means that one single Node can have several “coupled equations sets” it’s involved with! Simply put, each Node can belong to more than one Element, and each Element will put its own shape functions onto the Node.

You know, something like this:

What is problematic here is, that Element A shape functions are “independent” from Element B shape functions. It’s a different set of coupled equations. This means that both those Elements will “interpret” what is going on in the common Nodes (2 and 5) differently!

Before we get further, there is one thing I need to explain:

Typically FEA solver works like this:

It creates all the “single element” shape functions, and bash them into the stifness matrix for each Element separately.

When solver finishes this task, you have a LOT of small stifness matrixes (one for each element). Those aren’t “connected” together yet!

This connection happens, thanks to the common nodes between elements! Solver assumes, that deformations in each Node should be identical, regardless from which Element shape functions you use!

This means that the assembly of the global stiffeness matrix (from the small Element stifeness matrixes) is possible because we assume that deformation of nodes is “constant” across elements.

What this means is, that firstly, solver gets the deformations at the nodes. Then knowing what is the deformation between nodes, using Element shape functions it can calculate strain in the Element. This is pretty simple – if Nodes 6 and 9 got closer to Nodes 5 and 8 this means that the Element D on the drawing above is compressed in the horizontal direction. Since we know how much closer those Nodes got together, and what was their relative position we know the “shortening” of the Element D… which gives us strain!

Knowing strain, we can easily calculate stress, knowing the stress-strain relation we implemented in our FEA model.

Should we vote on what the outcome is?

There is one final twist in this story! All Elements “agree” what the deformation on each Node is (this is a requirement for global stiffness matrix assembly of our model)! The problem is, this is the “only thing” they agree on!

Let’s take a look at our small FEA model once more:

If you would “ask” Element A what is the stress at node 5 it would say:

“Since Nodes 1, 2, 4, and 5 moved in relation to each other in *this way*, this means that the strain inside me looks like *that*. Based on that I predict that the stress in Node 5 is equal to Y”.

Ok, I admit, it’s a bit more complicated mathematically, since our Element only knows the correct strain/stress value in Gauss points located within its boundary, but let’s keep it simple ok? Let’s limit our today’s discussion to:

Since Element “knows” how its Nodes moved in relation to themselves it “knows” what the strain in this Element is. Thanks to that, it can calculate stress within this Element boundary.

Truth is, Element does not have the “full knowledge” of what is going on inside it. It only predicts couple of proper answers in so called Gauss Points, and just estimates/extrapolates those few correct answers on the “rest” of its area.

Now we can get to the point:

The above means that based on deformations of various Nodes “belonging” to each Element, all 4 Elements (A, B, C, and D above) will attempt to calculate stress value in the Node 5 in the middle.

The problem is, that each Element will obtain a different value, based on its own shape functions! You know, Element A will use relative movement between nodes 1, 2, 4, and 5 to calculate its strain while Element D will do the same thing, but for Nodes 5, 6, 8, and 9. Obviously, this will lead to different answers in Node 5!

This effectively means that in the central Node we get 4 different stress values! Which one is correct?

Well, all of them and none of them at the same time! Often your post-processing software will use something called “stress smoothing” or “stress averaging”. Instead of showing you this “jumping” stress contour plot (that in all honesty shows “real” outcomes from FEA), your post processor will simply calculate the average of all the values in the Nodes (from all Elements) and show you only the average. This looks more or less like this:

Basically what it means is, that you don’t see the “correct” answer in the Node of interest. But rather, an average from all the answers each Element sharing that Node is producing! When you decide to plot an “unaveraged” outcomes, instead of one stress value in any Node, you will obtain as many different nodal values as many Elements share this Node!

Cool huh!?

… ok, I know it’s not cool at all! It bothered me as well. After all, a reasonable question is:

What is the outcome for crying out loud?!?

Mesh refinement for the rescue!

This is where Element size comes into play! Whatever model you have, on the sufficiently small scale the stress is almost constant in any given place. You just need to zoom close enough!

If you have a problem of big differences between nodal values in your model, the best approach then is to get the nodes closer to each other. Then, they are “almost in the same space”, so stress is “almost constant” and Elements will produce similar outcomes – a thing that we are interested in!

Also, Element quality is a factor. Shape functions work best if you have a square QUAD4 element. If this is not the case, and your Element has some sort of a “crazy shape” this is not helping! This will simply mean, that your Element may predict something “weird” simply because the shape of the Element makes the shape functions work improperly. This is why it’s always a good idea to take care to produce the mesh with good quality Elements (you can check Jacobians for that, or something from Barlows list in case of second order 2D QUAD elements). I would say, however, that the Element size “helps more” than Element quality in typical situations (unless of course, you do something “weird” just to prove a point!).

This is already getting long, so if you are interested in mesh refinement, it’s one of the lessons in my free FEA course:

Free FEA essentials course!


Beyond the spring – warning this is a Geek section!

Above, I used a nifty explanation with the springs connecting Nodes in Finite Elements. To be completely honest, this is not how it works. I mean if you would mathematically “untangle” shape functions those would not lead to such a spring “system” in QUAD4 elements. In fact, it would be a bit more complicated.

You see, the Element does not calculate strain based on how much each spring in our simplified model elongated or shortened. That would be too simplistic. Instead, it solves some not too difficult equations.

If you are interested in how this really works, I think it’s best to read a great article my friend Angus Ramsay is writing right now – mathematics is involved (be warned!)

Common questions about Nodes and Elements in FEA:

What is a Degree of Freedom?

I didn’t focus on that here. Each Node can “move” in space depending on what we assume in our analysis. In the 2D problem, Node can move in 2 directions (such movement is often called translation) and rotate in the plane of our problem. Each such “movement possibility” is called a Degree of Freedom (DoF). This means that a “normal” Node in 3D space have 6DoF: Translation along axes x, y, and z and Rotation around axes x, y and z. This is why usually in 3D you have the support option that lists all 6 of those.

However, 3D solid elements (lite HEX8) have 3DoF in each node… there is no point for the solid element to carry Rotations in its nodes… so it just carries Translations (solid elements deal with rotation as a translation difference between Nodes in a single Element).

Which Finite Elements are better TET or HEX?

Ha, this is a great one : )

There is no obvious answer. I mean, if one element type was “clearly better” who would bother to implement the other types right?

It’s a commonly known fact that TET elements are far easier to “mesh”. After all “TET and forget” is the 3D Finite Elements catchphrase. HEX elements require much more work when you have even not-so-complex geometry. But at the same time, TET elements have a constant strain in their volume… so you need A LOT OF THEM (and very small) to get reasonable outcomes. Sure, you can use TET10 (quadratic TET element), and those aren’t that bad.

I think it comes down to a question: how many times will you recalculate the model? If it will be a few times I think that HEX elements will run faster (but require time up front for meshing). On the other hand, TET elements mesh faster but compute longer. The observant reader would also notice that even as in both possibilities time is the factor TET elements increase “computer time” while HEX elements increase “human time”… definitely not the same thing.

And finally, HEX elements are considered “more elegant” in the FEA world. I get the feeling that outcomes obtained from HEX mesh would be more trusted on average : )

12 Comments

  1. Casey February 14, 2019 at 3:06 am - Reply

    Great article Łukasz! Thanks for taking the time to put together an article that explains fundamentals of FEA in a simple and concise manner.

    • Łukasz Skotny February 14, 2019 at 5:57 am - Reply

      Hey Casey!
      I’m really glad that you like it! Thank you for a nice comment : )

      All the best
      Ł

  2. Lukasz Nadolny February 14, 2019 at 6:05 pm - Reply

    Lukasz this is an excellent article. I miss only one part here. Mostly regarding Gauss point. Especially after reading your article people can have the impression that stress are directly in node points and that extrapolation it’s not so important. But this topic becomes more complicated when you consider shear locking effect and explanation with springs here don’t cover this without influencing the gauss point for elements.

    • Łukasz Skotny February 14, 2019 at 8:14 pm - Reply

      Hey Łukasz!

      Yea you are of course right. I think I mentioned Gauss points somewhere there, but I didn’t expand on the idea for sure. This is a tricky business as I don’t want to go deep into the mathematics of the problem, and I don’t have a clear idea how to explain those in a more “easy going way”. I’m sure open for suggestions if you have any how to discuss that without diving into mathematics 🙂

      All the best
      Ł

  3. Anwar February 14, 2019 at 7:17 pm - Reply

    Very good blog .It just reminded me of what Albert Einstein said. ” if you cannot explain something in a simple terms , you have not understood it yourself”

    Thanks Luk..for making things easy..I feel like going back to the college..hahah

    • Łukasz Skotny February 14, 2019 at 8:15 pm - Reply

      Hey Anwar!

      Dude, I envy you your college experience! On mine FEA was almost non-existent and when it was it was matrix operations :/ If my blog bring back the college memories then the only question that remains is… what college did you attend 😀

      Anyway, I’m super happy that you like this stuff 🙂
      Ł

  4. Mohammad Yakub February 15, 2019 at 5:20 am - Reply

    Nice article!
    Thanks Lukasz : )

    • Łukasz Skotny February 15, 2019 at 7:48 am - Reply

      I’m really happy that you like it Mohammad!

      All the best
      Ł

  5. Francisco February 17, 2019 at 2:00 pm - Reply

    Very clear and practical explannation. Thnks por sharing this.

    Regards

    • Łukasz Skotny February 17, 2019 at 3:32 pm - Reply

      Hey Francisco!

      I’m really happy that you like it – thank you for the comment!
      Ł

  6. Naweed February 20, 2019 at 2:27 am - Reply

    Hey Lukas,

    I am fascinated, to the say the least, while reading your posts. You engage the readers…full attention.

    Ok, while reading this article on nodes and elements, I have started to think how to explain CFD simulation in a similar, simple, lay-man, non-mathematic way. We create the same nodes and elements for CFD, but it’s a whole different world.

    It may not be your area of interest, or, should I say “business”??? 😉 but I think it would really help everyone understand …and probably motivate students further into CAE…

    • Łukasz Skotny February 20, 2019 at 3:46 am - Reply

      Hey Naweed!

      I’m really glad that you enjoy the article!

      Sadly, I never used CFD, and I try to avoid topics I know little about. I wouldn’t like to confuse anyone or even worse say something that is clearly wrong. So sadly CFD won’t appear of the blog, unless I find and specialist from the field that happens to write in “my style”.

      Have a wonderful day!
      Ł

Leave A Comment

Do NOT follow this link or you will be banned from the site!