(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');
18 minutes read
22 February 2021

Web under local loads – Lessons learned

18 minutes read

In the last few posts, I described how I would deal with the problem of local loading in the web of a relatively high-strength steel girder. This is a “fun problem” from an engineering standpoint, and I hope you learned something from those articles. However, the “real” reason I did all that is to compare the approaches and discuss their pros and cons!

There is no better or worse approach in engineering. So no one can say that nonlinear FEA is “better” than linear FEA in a “global sense”. Each approach offers unique advantages and suffers from problems not encountered in other solution methods. So, let’s compare hand calculations, linear, and nonlinear FEA in solving the local loads in the web problem.

I already did a lot of work in this field, you can read how I used different design methods in the following articles:

Here, we will just compare the above, but not only the outcomes. We will also consider the pros and cons of each approach!

Believing is often more than knowing…

In a typical comparison, you should start with comparing the outcomes, percentages, and all that other stuff. And we will get to that. But I want to tackle the biggest issue first! And it may seem trivial… You need to believe in the outcomes you receive!

This is actually a huge issue, and the amount of questions about “outcome interpretation” I get proves, that it remains at the top of the “problem list” for many engineers. So let’s see how believable the outcomes are in each case!

  • Hand calculations are just there! To be honest, I rarely have doubts about code procedures. In fact, after you learned how to use the procedure, knowing more makes you doubt it more. If you just learn what you need to use the procedure effectively, and then you stop learning – you will believe in it without much problem! And even if you know more, it’s not that the procedures are “plainly wrong” – they are often too conservative, but they offer “certainty” of the outcomes. For me, that is a good tradeoff!
  • Nonlinear FEA, the trick you need to get used to! Nonlinear FEA is a “funny thing”. I completely believe in the outcomes of the analysis that I perform. In fact, I may be willing to say that the code procedure is overly conservative in some cases. But I also know that this takes time, and I wasn’t always like this. There is something “scary” in seeing how much the model may yield, and there is always the fear of making FEA mistakes (you know, wrong boundary conditions, etc.). So it definitely takes time, and experience to trust in nonlinear FEA. It’s much easier with code procedures for sure!
  • Linear FEA… the unloved child! This one is… doubtful! If I got $100 every time I heard that “this stress is artificial” or “FEA is stupid, such outcomes are impossible”, I would probably get a Polish minimum wage just from that (this is not a lot of money, to be honest, but don’t feel encouraged to complain more to aid my financial situation :P). I’m certain there are people “believing” in linear FEA, some of them know a LOT (and thus they know what to ignore, etc.), while others know “too little” (been there, done that!). But I feel that the majority of engineers would “doubt” the sense of linear FEA outcomes!

Let’s try to put it on a perfectly arbitrary chart I just came up with:

The biggest doubt about the chart above is that it’s super arbitrary. I can easily imagine you have your own version of it. For me, the linear FEA will go way lower at the end, since I don’t trust it that much nowadays. On the other hand, I know people who would trust linear FEA more than codes, and they are experienced. So clearly this is a personal preference thing!

However, I will be willing to say, that I do trust nonlinear FEA the most nowadays. And I see codes as good (but sometimes unnecessarily conservative) estimates for various problems. And I would never base my design on linear FEA… but does it makes me “experienced”? I have no idea, as this chart is obviously limited by my own experience. Who knows, maybe in 10 years, when I know much more, maybe I will be able to add to the trajectory of the curves? I wonder how they will behave!

One way or another, I’m willing to call code procedures the winner of this part. I estimate that only a small percentage of design engineers use nonlinear FEA in “daily work”, so while they may believe nonlinear FEA more… “statistically” it’s the codes that are most “trustworthy”.

But I think that the most important message is different!

Regardless if you trust code procedures or nonlinear FEA outcomes more…

… linear FEA is just not as trustworthy as the other two approaches!

In my opinion, however much you know about the problem, linear FEA still “forces you to guess stuff”, and this makes me trust it way less than the other two approaches. It’s a good idea to remember that I think!

Stress capacity first!

Stress capacity theoretically should be the easiest to calculate (since it’s “the most obvious” part). It’s not so simple I’m afraid, as you will see below!

Stress by hand…

However, with hand calculations, it’s not so obvious what value to use as an outcome. This is because the procedure aims to simply provide you with the “total capacity”. So, naturally, it doesn’t provide “intermediate steps”.

And this is not a critique as such I guess… I mean, when I follow a code procedure, I’m interested in the outcome! In that case in “total capacity” that already takes into account all possible aspects of failure foreseen by the code. I just feel that if the codes would teach folks, how to calculate stress capacity, and then stability capacity, AND THEN how to combine those into the final outcome… engineers would understand more! But it would also mean way more work in the “process” so I’m not sure if folks would be happy with my proposal in the long run!

To extract stress capacity from hand calculations I have to do a small trick. I know that the final outcome was 315.8kN. But I also know, that the “buckling reduction factor” was 0.438. Knowing how the Eurocode procedure is constructed, I can then say, that the stress (plastic) capacity of our problem obtained from hand calculations is: 315.8 / 0.438 = 721kN.

I fully admit that this could be debated (since there is leff parameter, and it’s not obvious from the procedure itself what it takes into account and why). However, for the purpose of simple comparison, that will have to be enough!

Linear FEA guessing…

Second in the line is linear FEA analysis. As you may remember, we had to make a choice/guess based on stress distributions I obtained from various loads (as a reminder the graphic is below):

I described my thought process in the linear FEA post, here I will just note, that I’ve decided that I’m willing to accept stress distribution “C”. Which means, that the outcome I estimated was 380kN. Quite a difference from hand calculations isn’t it?

Nonlinear FEA answer!

The third option I used was nonlinear FEA. I feel that I should remind you that I “cheated” a bit, and I used a model with imperfections to check plastic capacity. In truth, this is NOT how I should have done it, but I’m super lazy, and the imperfections may influence outcomes here (a bit). It’s always cool to look at the stress state of such analys721kN is…

… but for us, the most important fact is that the capacity was estimated as 650-700kN from the equilibrium path, and “only” 600kN if plastic strains were used. As I mentioned before, I have a sneaky suspicion that without imperfections the plastic strains wouldn’t be so high, but it’s beyond the point right now!

Bringing it all together

It’s clear that code procedure and nonlinear FEA are in “another league” with linear FEA. Mostly because I could simply extract outcomes, without much guessing. It looks to me, that hand calculation produced the most optimistic outcome here, and that is 721kN/. Perhaps without imperfections, nonlinear FEA would produce a slightly higher outcome, but 600-700kN is still “close” to whichever value we will choose from.

Hand calculations with my poor guessing clearly stay “behind” with 380kN of capacity!

Here, I also want to point out, that it makes little sense to dig deep into those comparisons. Truth be told, this is just a “stepping stone”, and not the actual outcome of the analysis. But I think it’s already clear that linear FEA is starting to fall off, the deeper we dig into the problem!

For truth… and stability!

Usually, in Eurocode design, stability is “seen” as a reduction factor for plastic capacity.

As such, we could observe, that in hand calculations we are reducing the capacity by 0.438. That would be a “stability factor”.

We can “obtain” this value from nonlinear FEA as well (just for comparison). Material nonlinear analysis MNA (well MNIA really, since I didn’t make a new model without imperfections!), lead to a capacity of 600-700kN, let’s say 600 to be “conservative”. The final outcome from GMNIA (that would include stability) was 418.9kN. This means that the reduction factor was 418.9 / 600 = 0.697. Admittedly, if we would go with 700kN, the same factor would be 0.598 (simply because the final capacity doesn’t change, while I just changed MNA capacity).

First of all these shows, that such comparisons aren’t great unless you put much effort into estimating a proper “pure plastic” capacity in nonlinear FEA. And to be honest, you may not need to do that in many cases (just as I didn’t do it here). However, it’s quite clear, that the reduction obtained from nonlinear FEA is lower than that obtained from hand calculations. And to be honest… it should be like that! With nonlinear FEA you can simply analyze “precisely your case”, so you can be sure, that the stability problem you solve is “exact”. At least to the point of what imperfections you added to your model – sometimes several analyses are required (as you are not sure which imperfections will be the “worse” ones!). This is, however, a much more accurate analysis than the and calculation estimates. And as such, there is less “guessing” and less “just-in-case-safety” included in those procedures.

Interestingly, linear FEA produced a super small reduction! I “guessed” that the outcome is 380kN in pure stress capacity. Then I saw, that the critical force (from LBA) was around 800kN, so I decided to decrease capacity “a bit” to 350kN. This lead to reduction factor equal to 350 / 380 = 0.92.

And again, I wouldn’t read much into that, since this is mostly the product of how pitiful I had to guess the stress capacity. It’s quite obvious to me, that if I would guess capacity at the level of 700kN, and I would obtain a critical load of 800kN I would decrease the capacity much more than I did. How much? I cannot say (since I know the outcome already, my answer here would be super biased!). To be honest, I don’t think I would go from 700kN to 350kN. Maybe I would guess around 500kN? Hard to tell really, especially since I know that this is an overestimation already!

A bit more on stability…

Another point I want to make here about stability is a more general one. We have already learned that the actual “stress capacity” (the actual name I would use is plastic capacity, but that would sound really weird in linear FEA!) of our system is around 600-700kN. If you recall from the previous post, the critical buckling load was higher, 820kN to be precise!

So someone could say: “Awesome, stress allows for 600kN, stability allows for 820kN… I can assume that 600kN is the answer!”. And that is COMPLETELY FALSE!

With stress capacity and critical force being so close together, it’s obvious that they will interact. Ok, it’s not obvious – unless you’ve done quite some work in the stability design… or took my nonlinear FEA course 😛

I think that one of the most important conclusions you can take away from this is:

Never assume that if the stress capacity is ok, and the critical force is higher than the load, you are in the clear!

Sadly, the stress and “critical” capacity of the system will work together to destroy your model! The closer they are to each other, the more they will cooperate, resulting in a reduction of the overall capacity below the value of either.

Here, the outcomes are as follows:

Stress capacity: 600kN (to be conservative, from nonlinear FEA)

Critical capacity: 820kN (this always comes from LBA, since outcomes of nonlinear FEA with imperfections is not “critical” by definition)

Final capacity… 418.9kN, which is 30% lower than the stress capacity, and 51% lower than the critical force!

One to rule them all!

Let’s finish with a decent summary!

I used 3 distinctive approaches, and the FINAL outcomes (those that include both plasticity and stability) for each method were:

  • Hand calculations: 315.8kN
  • Linear FEA: 350kN
  • Nonlinear FEA: 418.9kN

On the outside, one could think about it as a “progression”. In some sense, it looks that hand calculations (that seem to be the most “primitive”) produced the most conservative outcome. And then, doing linear FEA allowed for some “better outcomes”, while the nonlinear approach was clearly the best.

But I hope, that as you read this, you already know that this is only the surface level of the discussion. While I could say I was not sure about some equations from the hand calculations procedure… at least I saw “sense” in most of them, and I could assume that the rest is correct. While this is a significant assumption, at least the procedure is published in a super-official and (hopefully!) well-verified document.

On another hand, when I did an analysis with linear FEA… I was more or less guessing all the time! While the outcomes look decent (and definitely would make my report look “smarter”), there wasn’t that much certainty to them. Also, the stress capacity of the system I estimated was the lowest by far in all of the choices, and the influence of stability was pure guesswork! Definitely my least favorite method!

And finally, the nonlinear FEA produced a nice animation (I know it’s a lame argument, but I really love those animations!). But it also gave me equilibrium charts I could analyze (along with other limits, like allowed plastic strains, etc.). The outcomes made me feel good, and I could understand what I’m doing along the way. But it should also be pointed out, that the computing required an hour (and I run a decent machine), and it required relatively expensive software (the linear analysis can be done way cheaper for sure!). I mention the prices fully aware that there are open source solutions out there too – but at least for me, it is a valid argument or at least something we should not ignore!

And the winner is…

There are no winners! But there definitely is a loser!

Code procedures!

I would consider the code procedure to be a success in our case! It allowed for a very quick outcome, and the accuracy was actually pretty decent (and conservative which is a safe-side thing!). But note, that it would be plain stupid to “extend” the conclusions of this comparison too far. After all, there are a lot of code procedures, and I’m not a huge fan of some of those.

I’m usually willing to assume that the code procedure gives a decent (if slightly conservative) estimation of whatever problem I am trying to solve. This is a super useful thing! The problem is… there aren’t that many code procedures! Most “real-life” engineering problems are more complex than what code allows you to verify! This is a problem of course, but the biggest drama is, that if you focus “only” on the code procedures, and you will encounter a complex problem… you may ignore issues you should not ignore! And this is never a good idea in engineering!

So, good code procedures are AWESOME, but if you are trying to solve a problem not covered by the procedure (or covered only “a bit”) things will get slimy! And this is a thing many engineers miss. I would call this attitude as: “since it’s not in the code, I don’t have to worry about it!”. That is a VERY DANGEROUS attitude in my opinion, and it doesn’t fit with the engineering art! After all, codes are quite new things really, and before that… things were build and worked, yet nothing was in the codes!

Limitations can have various faces. In this particular case, imagine that there is a stiffener under the top beam running for the upper half of the bottom beam height. There is no way to take that into account in the code procedure… since it hasn’t foreseen such a solution!

Linear FEA!

This must be the ultimate extension of the “I did it on the computer so it must be correct” argument! I hope that by describing my thought process, I showed you how much guessing is involved in linear FEA design.

But does that means that linear FEA sucks? No, not really. This is still a super useful thing, as it can show you how the stress travels through your element, and place some warning on certain parts of your model. But when the “final verdict” has to be made (God forbid optimization!), you are just guessing. And while it’s an educated guess… it’s the guess all the same in my book!

But there is a hugely important aspect of this, and that is – you need to start somewhere! Expecting from someone that they will instantly start doing a Ph.D. level nonlinear analysis of each problem they encounter is… slightly unrealistic! And linear FEA is just a starting point. If you know how to properly do linear FEA, there is A LOT of things you already know, that are super important. You know, things like how to support or mesh your model, display interpret answers, what loads to apply, etc. Linear FEA is a very important step in your engineering career! Just make sure it’s not the last one!

Nonlinear FEA!

It’s quite obvious, that I will state here that nonlinear FEA is the most accurate approach. Furthermore, you can analyze almost any problem with nonlinear FEA, and that is a HUGE advantage. But is it a “clear cut” winner? I’m afraid to declare so!

You see, there is a huge effort involved with nonlinear FEA. You have to learn how to do it, have access to software that allows you to do it, and then have time to actually do it! And those things are not obvious nor given!

I do admit that my company specializes in solving difficult problems. Those often don’t have associated code-procedures, and yet they have to be solved “somehow”. This is exactly where nonlinear FEA thrives! To be honest, in my opinion, nonlinear FEA is the ONLY available engineering tool to solve such problems. Perhaps, the other solution being super complex math and differential equations – I don’t know anyone in my field who went down that route, but I guess this could be done at least to some degree!

But if you are trying to solve a more-or-less typical problem with a well-established code-procedure… it’s absolutely not obvious if nonlinear FEA will be a better choice! Sure, the outcome may be less conservative, but the effort to obtain the outcome is way higher! I guess that would mean, that it makes sense to use a nonlinear FEA approach in optimizing serial products etc. Since then, the cost of the optimization is gladly covered by the number of units that will be later manufactured. But if you are trying to solve a relatively simple one-off project… use code procedures instead! Just make sure you understand them correctly!

You can learn even more!

If you like my style of teaching, definitely check out my FREE online FEA course. You can sign up below.

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!

Join the discussion

Comments (2)

Michał - 2021-02-25 14:47:08

Hi Łukasz,

It's a great blog, you’re the man!
The only thing I don't like in your story is the boundary conditions of the model you made. As you would say "real life" of engineering is a little bit different. In a real structure span of the beam is a way larger which means the supports are not that close to each other. Of course, I didn’t check it with my calculations but I am almost certain that the stress distribution in the web is a “little bit” different when you change proportion of web depth (or height, as you describe) to supports spacing. In your model the spacing is not even twice bigger than the web depth which let me suspect that the stresses are distributed on longer part of web according to its local rigidity than it would be in a longer beam (in this case you need to improve the supports to fork-type). The question is how much is the “little difference”. From my studies of similar issues ( though far less deep than yours) I can say it can vary a lot.
Also, we all of us need to remember that Eurocode is a result of long discussions of many experts of their great experience. It’s enough to say that the current version is completely different than the one which was proposed at the beginning and there were over a hundred different ones between them actually. Unfortunately we cannot manage to analyze all the discussions which would certainly be a pretty awesome experience, I guess.

Can’t wait for the next episode.

Take care,
Michał

Reply
Łukasz Skotny Ph.D. - 2021-02-25 15:57:05

Hey Michał!

Thank you for your comment - I really appreciate this!

Indeed, the width of the beam isn't very "engineering friendly. This is sadly something I had to go to, as a means of a certain choice. I didn't want to add the compression in the web in the longitudinal direction (that would come from bending). That would make the EC procedure quite complex, and I really didn't feel like describing all that in a single blog post (since it was long enough as it is).

And since I omitted the longitudinal compression in the first post, I needed to make a model where it won't really play a role - and hence the short beam.

I never did studies on how much this would change for longer span beams. I mean, the longitudinal compression would definitely change the outcome (at least a bit) but this was not considered in all of the cases that I compared here. In the end, I feel, that everything can be done better, and my posts aren't any different than the rest of the reality that surrounds us. I did them the best I could given the circumstances, but if you would ever make such a study with the width of the beam, I will be more than happy to collaborate with you to write another post on this subject expanding the topic even more!

As for codes, I do agree that writing those is not easy, and I was never interested in doing so (I had a chance at one point). Knowing this, I would never directly critique a procedure unless it is "plain stupid" (and this is rarely the case... or so I hope), or when I feel I could do a better one myself (and that is never the case!). I'm aware that things are more complicated, and this is more or less what I wanted to show here. That if you have a procedure then it's great... but those usually cover very simple cases and nothing more... so if you encounter anything more tricky, you are on your own anyway...

Thank you for sharing your thoughts Mate!
All the best!
Ł

Reply

Sign up to newsletter

and get Free FEA Course!