(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-5M6SH59');
21 minutes read
9 November 2020

What every engineer needs to know about FEA

21 minutes read

I remember feeling overwhelmed when I started to learn FEA! It’s just too much to deal with at once! Gathering my experience from running an FEA design company I will do my best to share with you, the most important aspects that you really should know about.

There are a lot of things you can learn in FEA. Focusing on the wrong ones can really slow you down (and bore you to death!). I strongly believe that focusing on engineering skills is critical (and not obvious!). Let’s discuss why!

This is a somewhat personal topic for me as well. I have very strong feelings about a few things (as I’m sure you will notice). I’m not happy with how FEA in general is being taught, and I guess I have my own personal rebellion about this on the blog. Let me know what you think about it in the comments, especially if you do not agree with me because I’m always happy to discuss this!

Understanding FEA…

I admit that I wanted to add this section at the end, as a final conclusion, but I decided to start with it instead. This means that right from the start you will learn what I think you need to know… instead of learning what you don’t need (and why!). While understanding what you shouldn’t learn is also super important, perhaps it’s more “positive” to start with something that you should actually do!

Garbage in – Garbage out

You have definitely heard this sentence before, and obviously, it’s true. Doing FEA is like asking a computer a question. If you ask a stupid question… you will still get an answer. The problem is, the computer will always make its answers look “smart” (you know, contour plots!). Furthermore, the answer that the solver gives you is always correct (ha! I’ve got you here, eh?). This makes a lot of people simply trust in those answers “blindly”… after all, they are always true!

The problem is, that the answer you obtain is for the question you asked… not for the question you SHOULD HAVE ASKED!

So the problem is not in how the computer “thinks” when it gives you the answer! Let’s face it – the computer won’t lie to you! Whatever question you ask, the answer will always be “true”. Ok, sometimes you may ask such a stupid question that there will be no answer (I’m looking at you non-convergence!). But to be honest, as frustrating as it is, no answer isn’t very dangerous… because you instantly know that “something is wrong”. I’m way more worried about folks who obtain true answers… but for the wrong questions!

An FEA nightmare story!

Imagine that you are in a foreign land, and you barely speak the language.

Using a dictionary you ask for the road to the station. The person you ask knows the city perfectly and draws you a beautiful map…

… while the map is super cool and looks beautiful, it also has a LOT of information on it. In fact, way more than you need! A lot of things are marked with symbols you need to figure out. It’s obvious that the guy who has drawn you the map knows the town perfectly and also has all the information about it. But digging through that is a bit difficult, and it takes some skill for sure. Still, you are certain that this guy is able to draw you a map to anywhere!

Anyway, you figure out enough to follow the map… and you end up… in the town square! No station in sight!

You frantically look at the map – you think you have interpreted it correctly! But this cannot be! The guy did the map so nicely… maybe he is just stupid?

And what you don’t know, is that while using the dictionary you messed up… and actually ask for the road to the town hall! You got a correct answer but to the wrong question! And while the answer is correct… it didn’t help you at all! In fact, it could put you in more trouble!

I think this is a very neat metaphor for using FEA. It’s very easy to *think* you modeled the problem you wish to solve. But while FEA will always give you the proper answer… it may not be the solution to your problem. Whatever the case may be, understanding that answer is complex in its own right!

To use FEA correctly, you only need to know:

  • How to ask the question YOU SHOULD ASK, to get an answer that you need! This is a pretty difficult thing! Mostly, because it requires your understanding of what you are doing. So even before you start modeling your FEA problem (aka asking the question), you should be able to have some idea of what the answer should look like. But you also need to understand a lot of things, to ask the question properly!
  • How to interpret the answer that you received! Depending on the case, it may be easier or more difficult to understand the answer you received. The general rule is, the more complex the question, the easier the answer is to understand. But without a doubt understanding the answers is an art of its own!

While the above may seem simple, there are some questions floating in the background. You know like: “what is the role of FEA software?”, and “do I need to know mathematics in this whole mess?”. We will have to ask those questions on another occasion, here let’s focus on the above.

First thing you need to know:

FEA will always correctly answer the question that you ask (by defining your model). The problem is, that if you ask the wrong question, you will get the correct answer… that is NOT the solution to your problem at all!

Understanding the FEA answer is a tricky thing in its own right! While asking a proper question is very important, interpreting the answer may not be trivial either!

Asking the right questions!

Asking the proper questions may be the most difficult thing in FEA design. I guess it’s just as difficult as writing a solver that will compute the answers… with the difference that you can always buy a solver somebody else wrote and tested… whereas you are the only person that can describe the problem you wish to solve!

So what do I have in mind here? If you read my post about how to do FEA by hand, you already know that it finishes with a “cruel twist”! In essence, I showed there how to solve a simple problem by hand… and then at the end revealed how complex the “real problem” is. And this is the thing! Most engineering problems are way more complex than you initially think!

And the complexity of those problems is in their “nature”, which has nothing to do with FEA as such! They are complex regardless of which method of solving them you select! And grasping that complexity is necessary in order to ask the right questions for your solver to answer!

I will use a simple example I used in the applications of the FEA post I wrote a few months back. Imagine a wooden board that you try to use as a footbridge over a stream. A pretty straightforward task eh?

Let your imagination run wild and wonder what could go wrong! My list would be something like this:

  • I’m too heavy – the board will break under me
  • The board might deflect too much… I wouldn’t feel comfortable walking on it
  • There is a gnarl in the board… maybe this place will break unexpectedly?
  • What if the riverbank is too soft and the board slides into the water at either end?
  • Maybe I should also consider someone heavier going over my footbridge later?
  • What if that guy takes a wheelbarrow of sand with him!?
  • Will this board withstand years of usage, or should I replace it every now and then?
  • Bugs can eat my board – if I fail to notice, I might get wet…
  • If I run too fast, the board might “jump” with me and fall into the water
  • If I accidentally kick it to the side it might be too light (friction won’t help in such a case) and fall into the water

I’m pretty sure you get the point – there is A LOT of things that can go wrong even in such a simplistic problem! And let’s face it – the industrial design cases tend to be slightly more complex!

So you may suspect that I want to go with “you need to deal with all of the possible problems” to be an expert. But that is not really the case! You need to be able to foresee all of them – sure! After all, you cannot verify a problem, if you don’t know that the problem even exists! But you also need a way of “filtering out” the problems that won’t be important, that you choose to ignore! After all, you cannot spend a lifetime solving a single beam! This process is called “idealization” and is one of the critical components of being an FEA expert.

Did you notice that this has nothing to do with FEA math? Most “FEA math” tutorials start with: “you have a simply supported beam loaded with a single load in the middle” or something similar. So our footbridge with you on it would look like this:

And a good designer should instantly ask:

  • Why is the beam simply supported? If both supports are the same, why does the model have a sliding support (on the right) and one non-sliding support (on the left)?. Who decided that? And is it even correct?
  • Why are the supports infinitely rigid in the vertical direction? Is it possible that support rigidity will play a role here? What about in the horizontal direction?
  • Can I treat the load as static? …and many, many more questions like this!

Notice, that those questions have nothing to do with FEA… they are just “in nature of the problem” as we try to idealize it! After the idealization is done you can calculate this yourself, or run a solver of your choice… but by idealizing your model, you decide what your question to the solver will look like!

Idealization + FEA

But why does the problem of idealization come up in FEA more often than with hand calculations? Mostly because FEA can simply do more! The process has been around the whole time we have done any engineering design (way before FEA was even invented!). But originally, idealization was used to simplify the problem so much, that we could solve it at all! There was no point in wondering if a problem was more complicated or not… if you couldn’t take that complexity into account anyway!

This means, that historically idealization was BRUTAL! Most complexities were removed from the problems (rightfully or not!) simply because there was no way to calculate them otherwise. So in some sense, the problems were brutally dumbed down, so engineers could solve them “more or less” with available methods.

This may sound as if I’m opposed to using such methods… and this couldn’t be farther from the truth!

This brutal idealization is a great trick to learn! Even if you want to solve super complex FEA problems, it’s a great skill to be able to dumb down the problem you’re solving to a task you can solve by hand. This way you will be able to calculate an estimate of an outcome and compare it with FEA. Of course, you will never “ace it” (if you can… don’t do FEA, just solve the dumbed-down models – it’s quicker!). Instead, you can see if the FEA outcome is “within reason” – which is a super skill! This is why you may hear, that if you don’t know how to solve a problem without FEA, you shouldn’t use FEA to solve it.

I admit this is a harsh statement (and there will be cases when it doesn’t hold)… but there is definitely the case that understanding the problem enough to solve it approximately by hand is a skill of great value. It also aids you in designing things correctly, and in building proper models! Note, however, that this has nothing to do with how the solver does the FEA math! – It is about something else, and that is “by hand” design skills! This is a completely different, design-oriented skill set!

The second thing you need to know:

The problem you are trying to solve is most likely way more complicated than you suspect! In the past engineers were able to brutally simplify the problems, simply so they could solve them!

Being able to brutally simplify a problem is a great skill, as it allows you to do simplified hand calculations to check if the FEA outcomes you obtained are within reason!

Idealization in times of excellence!

Let’s take a look at idealization from a slightly different perspective – it’s a double-edged sword after all!

It’s great to be able to dumb down the model to quickly estimate the answer. But we also have tools at our disposal that allow for much more complex analysis than even a few decades ago! And FEA is a great example! Simply put, we can solve such complex systems in FEA, that would be undoable with pen and paper. So we can take a LOT of complexities into account in our designs. Complex FEA models make our designs better, more robust, and cheaper to execute! But in order to use them, you need to be aware of the complexities you wish to acknowledge, and know how to take them into account in the first place!

So while it’s great to be able to do a brutal idealization from the past… it’s also important to know that it’s not enough nowadays!

As we progress with more and more optimized designs, while doing more and more complex structures… brutal idealization cannot be the only method we use in design! Simply put, stuff we design is so complex, that we need better tools and more accurate models! Otherwise, the designs we produce won’t be optimized enough for current market needs.

This is where numerical analysis kicks in! FEA is the ultimate tool for solving super complex problems! The thing is, that you need to be able to formulate the proper question! And again, it’s not about understanding how FEA will solve the problem. It’s just a calculator that does math routines. What you need to know, is how to model a problem, to receive a proper answer!

And this is the modern idealization! It’s the skill of “seeing” the potential problems, and the ability to incorporate them into the model that can be solved by FEA. It’s a very difficult skill, as it requires a lot of engineering knowledge and even some experience… so gaining it is challenging. But when you get it – you really start to understand the things you design! I would list the following as components of this skillset:

  • Understanding how to support models. The division of “pinned support” and “rigid support” isn’t obvious anymore. Often, you will have to deal with semi-rigid supports, which will also require the ability to estimate the rigidity of those supports! Plus, it’s often not obvious which direction is blocked, and which are not in given places – and you need to be able to navigate there easily to be successful.
  • Reasonable modeling. You know, things like “how to represent what I want to solve, in a way that it makes sense”. Adding unnecessary details to your model is just as bad as removing the important ones! But to judge what is important, you need to have engineering knowledge about how things “work” in reality! But this step also includes meshing. And while you definitely don’t need to know how the shape functions calculate strains in your elements step by step, you definitely need to be aware that poor mesh gives poor outcomes, and you should be able to identify what a “decent” mesh looks like! (You can always read about mesh convergence here!). Not to mention that you need to know enough to make a call if you should use 1D, 2D, or 3D mesh. Again, this doesn’t require extensive math knowledge, but understanding the pros and cons of various elements is important for sure!
  • Understanding how loads work! And I mean in reality, not in FEA. You can enforce deformations or apply active loads. And usually active loads come from things. Those things have their own rigidity, that may play a role in your design… don’t forget about such things!
  • Understanding structures in general! Sometimes things seem straightforward, but when you look closely enough, you will realize that there are things “happening” you just haven’t thought about. And those things can have significant consequences too! Being able to foresee that something will buckle, for instance, give you the chance to analyze the problem!
  • Separating the wheat from the chaff! Without a doubt, most models have a LOT of details about them! And most real-life problems are super complex. While it would be awesome to be able to analyze everything you need to be realistic! You can’t just analyze every problem, even the most minuscule one… you need to understand what is “really” important, and what isn’t. Those decisions will drive your idealization in the long run!

The above comes from understanding engineering mostly. This is what makes them “difficult”, as it’s not easy to build a robust engineering knowledge in any field. But I’m sure you will get there (if you are not already there that is!). I admit, that some FEA knowledge is needed, but it can be boiled down to quite simple things really (like the mesh convergence I already mentioned). And even if you meet someone who says that all of the above comes from learning how the solver does math… ask them “Which of those equations tells you how to support that model?”.

The third thing you need to know:

While being able to brutally simplify your model is useful… this is not enough now!

We start doing more and more daring and complex structures, and those require way more accurate analysis, than the brutally simplified approach!

This is why you need to know how to properly idealize your model, in a way that takes into account all the important things in your problem, but remains as simple as possible at the same time (with no “unnecessary complexities” added!).

Reading the map!

What we have discussed so far, allows you to ask the proper question! But you also have to understand the answer!

Without a doubt, FEA outcomes look beautiful (at least to me!). There is something “magnetic” and “professional” about those contour plots! Just remember, that this can be a map to a different place than where you want to go to! The fact that you see the outcomes, doesn’t mean that it’s the solution to your problem. It is only the answer to the question you asked… and the usefulness of that answer depends only on the quality of your question!

This is the first part of understanding outcomes!

The second part comes again with an engineering understanding of stuff! If you don’t understand how stresses work… it doesn’t matter if you calculate those stresses by hand, or with FEA. You still won’t understand their meaning! But those calculated with FEA look so “professional” that their view can fool you into thinking that you understand that! Don’t get fooled so easily!

This can be said about most FEA outcomes. After all, if you don’t understand the significance of strains in your material… does it even matter if FEA calculated them for you? And please note, that the fact that you know how FEA calculated them… doesn’t mean that you know what to do with them either!

Of course, similar examples can be made about deformations, buckling, fatigue, and other important aspects. If you know how to use the outcomes, then you know how to use them (regardless if you calculated them by hand, measured in a test, or computed in FEA). And if you don’t… then you don’t! It’s more or less as profound as that!

But FEA brings some additional problems to the mix! Those are secondary in my opinion, but they are there nonetheless!

When you calculate stress by hand, you can be sure what the value is! If you calculate the stress in FEA… well it depends! As long as you know how to properly mesh your model (this doesn’t require you to know the ins and outs of FEA math BTW), the impact of such problems is small. Usually, it’s simply negligible in engineering work, but if you don’t know about proper meshing… then you can get such bizarre outcomes that it would make your skin crawl! The cool thing is, that if you have decent engineering skills, you will instantly know that something is “off”.

Also, this problem is relatively simple to solve! If you are not sure about the outcome, calculate the same thing with double the mesh count. If the answer didn’t change – you’re ok. But, in case the answer did change, repeat the process (double the mesh count again, etc.). If you do it a couple of times, check if that is not a stress singularity (you will quickly learn to recognize those in linear analysis!).

Of course, you still need those engineering skills to be able to say “if this stress is acceptable” after you get the proper outcome. This is a tricky thing in linear analysis, since you can even get stresses that are higher than yield, and still be ok (check my small presentation about it here).

There is a pretty funny thing happening in FEA:

The more difficult a question you ask, the simpler the answer will be to understand!

What I mean by this is, that if you are running a linear static case, and you get stresses higher than yield… you can’t be sure if this works or not. But if you do nonlinear FEA analysis, then you can check plastic strains, and see if they are still acceptable. This is a way easier thing to do, and since allowable strains are usually defined in codes (like EN 1993-1-6 or DNV RP C208) you can simply compare what you’ve got with the allowable value… and you are done!

This means, that more complex analysis, gives you “better”, but most importantly easier to understand, outcomes! So learning those complex analyses is pretty useful, although they demand extra effort (and computing time!) for sure!

The fourth thing you need to know:

When you have a perfect model, the work isn’t done yet! When the dust settles, and you receive outcomes from FEA… you still need to analyze those!

In many cases, analyzing outcomes is done exactly the same as if you would get the same answers from hand calculations (so it’s not really an FEA thing, rather an engineering thing!). Having the knowledge to analyze the outcomes is of course super important, regardless of the design method!

But FEA also has a few twists. Usually, hand calculations cannot deal with “weird geometries” so in FEA you will get a lot of stress concentrations. Those are there in reality… but there is no way to calculate many of those “by hand”! This means, that they “stay hidden” in hand calculations and you see them only if you do FEA! Having a good engineering understanding of such things is definitely important, as it allows you to interpret outcomes correctly.

Also, if you would do a very poor mesh, the answers you may get will be just gibberish. Doing mesh convergence, to ensure that your mesh is “good enough” solves that problem. The cool thing is, that mesh convergence, while sound scientific is very simple to do! All you need is to calculate the same model with smaller and smaller mesh, and see how the answers change!

Thank you for reading!

I really hope that you’ve learned something interesting today!

If you don’t agree with me, I would be more than happy to discuss this with you – just let me know what you think in the comments below!

And finally, if you think that my English got suspiciously better recently… well it didn’t! The fact that you were able to read this and not grind your teeth because of all the language mistakes I usually do, it’s only thanks to Adam Djili who was so kind, that he checked this text for me!

All the best, and see you around!

Author: Łukasz Skotny Ph.D.

I have over 10 years of practical FEA experience (I'm running my own Engineering Consultancy), and I've been an academic teacher for a decade. Here, I gladly share my engineering knowledge through courses, and on the blog!

Read more

10 Lessons I’ve Learned in 10 Years!

Get Essential FEA Course for Free!

Comments (14)

Emily Bennette - 2020-12-30 22:07:12

I liked that you pointed out that you will want to make sure that you consider getting an FEA report done because it can help you find problems. It does seem like if you are going to be building something you should know if there are going to be any stressing it will be under. It does seem like a good idea to get an expert to do the inspection for you.

Łukasz Skotny Ph.D. - 2021-01-03 16:37:45

Sure, FEA has a lot of cool uses, and expertise in the field is a really great thing :)

Vinayak - 2020-12-08 06:00:39

Hi Lukasz,

It is simply great to understand what is the deep meaning of FEA and my thanks to you for upgrading my knowledge.

Łukasz Skotny Ph.D. - 2020-12-09 07:56:12

Sure thing Vinayak!

I'm glad that you like the article :)

All the best!

Matej - 2020-11-19 10:54:35

Hi Łukasz!

I really like your way of explaining engineering stuff. The topics that you address are some kind of white spots on engineering (!) faculties. When a young graduate comes in real engineering environment he usually realizes that solving equations is not everything and that there is much more to solve engineering problems. Questions like what loads actually acts on the structure or when the structure is rigid enough comes to my mind. I went trough this kind of questions myself and it was very frustrating for me. I was not lucky enough to find a book that would address those problems. All structural books simply starts with tensors and stuff ... Your approach is different and I really appreciate that you are trying to teach/share the whole picture of engineering.

Anyway, I think that understanding of math and equations behind FEA is important and as Stephen said ... "There needs to be a balance..." between math and engineering.

Keep up the good work!

Łukasz Skotny Ph.D. - 2020-11-20 15:37:52

Hey Matej!

Thank you for sharing your thoughts!

Without a doubt, there are white spots in the ways we teach engineering and I doubt my little crusade will change much in this regard... but you know I do what I can :)

And indeed, there is a certain lack in books, and I miss it as well - I even have ambitious plans to write a few to help out... we will see how will I manage that!

As for math and balance, without a doubt, it's better to know something than not to know it. And I do agree that at some point at least some conclusions from the "behind math" are very important. Is the math itself that important... perhaps. The longer I think about any problem (this included) the more I realize that nobody is right and that the truth is more complex). I guess that my "no math" approach, comes from the fact that this is the only thing I've got in terms of education (I mean useless math that didn't help me in ANYTHING!)... and this naturally produces frustration. Perhaps if I would have been receiving 80% of engineering skills and 20% math I would appreciate the math more... as of now I treat it as an "oppression tool" used at Universities!

So, yes balance is needed but I don't believe it's a 50/50 thing. How much of the 100% should be math - I don't know... but I would guess that it would be a small portion for me :)

All the best!

Stephen Brinkman - 2020-11-15 18:34:01

Thanks for that. I learned FEA "on the tools" from other structural engineers over many years (let's just say retirement is way closer than graduation). Recently I completed a masters that included a course on FEA. While we started with the maths (that nearly put me off) the outcome was very focused on the engineering "why?".
I found this all to be very useful, bringing the practical learning into a maths co text and vice versa.
I guess what I am saying is I agree with what you have written but that without the understanding of the basics of the maths decisions can be made by trial and error, or "because it was how I was taught". There needs to be a balance and clearly most courses have far too much maths and not enough engineering but we should be careful not to ignore the maths framework.
Yes, about half way through I was wondering who had improved your English :-), but considering it is not your first language I was never that worried.
Keep this up. I must share your blog with my new colleagues as we do a lot of FEA.

Łukasz Skotny Ph.D. - 2020-11-16 16:53:22


Ach, this is such an interesting comment Stephen! Thank you for posting (and for sharing my work).

Indeed we focus too much on mathematics when we teach FEA at Universities (like WAAAY too much!), so my natural reaction is to go in completely opposite directions. But there is a risk there to be "too extreme" in the "no math" way in my case, and I should be more careful about it I guess! The problem is perhaps that there aren't many resources that teach you math without the super-complex calculus and all the details, while I would really enjoy a more "overview" approach myself. But this should not be an excuse I guess! So I guess that the "call for balance" is just as well for me in such a case, and thank you for pointing this out so nicely!

Yea, second language or not I'm dyslexic which makes stuff a bit more entertaining when I write stuff :P But I'm glad that you enjoyed a "better English" version of my work. All credit goes to Adam of course :)

Harish - 2020-11-12 07:25:32

I just wished i had a teacher like you while I began my journey with FEA. As always great insights sir!

Łukasz Skotny Ph.D. - 2020-11-12 09:14:55

Hey Harish!

Thank you a lot for your kind words, it really means a lot!

With my best wishes!

Kristian Casupanan - 2020-11-12 02:36:25

As a recent graduate of mechanical engineering and a 1year experience in engineering design, I DO AGREE all the points were listed. The skill of understanding "how to ask properly questions" was PERFECTLY DEFINED here. I was very happy that I read all through the end. Thank you very much sir for sharing this great experience!!

Łukasz Skotny Ph.D. - 2020-11-12 09:16:10

Hey Kristian!

I'm really glad that you like the article and found it to be worthwhile!

With my best wishes!

Petar Petakov - 2020-11-10 20:07:10

Great article as always. Simply represents the most important fea stuff engineers need to take into account with simple examples.
Thank you, Lukasz

Łukasz Skotny Ph.D. - 2020-11-11 11:54:35

Thank you, Petar!

I'm really glad that you like the article! Thank you for commenting :)

All the best!


Sign up to newsletter

and get Free FEA Course!