How many load combinations are too many?

In this article, we will discuss load combinations in structural steel design based on Eurocodes. But this is an universal problem also visible in other codes and for other structures as well.

Most design code rules for loads lead an enormous amount of load combinations, usually going into hundreds. While accurate and in some sense “correct”, this approach leads to an insane amount of data. Data that can’t be easily analyzed by a human… leading to issues with design!

Let’s dive deep into the subject, and discuss what this means to all of us.

The reality of Load Combinations

I feel that I should start by saying that I don’t think this is a “stupid problem”. A thing simply generated by “stupid codes”. This article is not a critique in any way. Think about it more like a practical approach to solving a real problem.

The amount of load combinations generated “by the code” actually makes sense. Mostly because of the probabilistic approach to load combinations which is absolutely true.

Let’s start here: If we want to discuss loads on structures we have to agree on those points first:

• We need to design the structure to withstand higher than average loads of the considered type. We don’t want it only to withstand average value of the load (i.e. average snow). Simply because such a structure will fail 50% of the time, when load is above average.
  Clearly, we need to have a probability of failure much lower than 50%. This means that the loads we will use will be significantly higher than their average value.

• Loads that are significantly higher than average, appear rarely in real life… So rarely, that the probability of wind load and snow load to be highest at the same time is minimal.

The above two, will instantly lead to a conundrum. It seems the the rules we should follow are:

• We must consider higher than average loads to design safe structures.

• We must consider loads together if they can work together (I always use wind and snow for this)

• Those maximal, higher than average loads do not happen together!

It’s very easy to see, that while all of the above are good rules, they contradict each other.

And this is where the reduction factors kick in. It is obvious that you want to analyze the structure with highest snow load or highest wind load. But you don’t combine those. If you will use the highest snow, you will reduce the wind load value that you will use with it. Simply to consider what is the probable wind load when the snow is the highest. But at the same time, when you consider highest wind, you will reduce the snow in turn.

There are many terms you can use for this. The maximal load you take is called “primary load” (I call it “main” in my head). The reduced ones are usually called “secondary loads“.

The thing is, you don’t know which load is the “worst one” for your structure. Heck, most likely, there is no single “worst” load! Each element of the structure may have a different load that is “worst” for that particular element.

In such case you do what any reasonable person would:

You analyze all possible cases! You treat each load as a primary load, reducing all other loads in a given load combination.

Obviously, this leads to a situation where you have many load combinations!

But this is not the end. It’s a rear case, that “the load” is just a single load. Usually you have various load distributions (i.e. snow). This means that a single load “type” can have many “possibilities” and you will want to check each of those. The same can be said for load directions (i.e. wind), and again you will analyze many of those.

This usually leads to insane amount of load combinations. Especially when you consider a bit more advanced Eurocode approach. There are rules that propose more than one equation for each combination to further reduce some of the loads!

In truth, this is an issue… but this issue is generated by an actual problem! I will admit openly, that I don’t like so many combinations. But I’m not blind to the fact that this seems to be a very nice solution to this problem. So the thing is not trivial at all!

Where exactly is the problem?

I just told you, that generating all those load combinations seems to be a nice solution to the problem. Especially nowadays, when all those load combinations will be solved automatically, right?

So why do I even care, and write all of this?

You see, the issue we run into is that we can’t really analyze outcomes from hundreds of load combinations accurately!

Sure, we can do envelopes of outcomes, export maximal values, or even do envelopes of design outcomes. This happens all the time now, and there is a good reason for it.

But we can’t take a deep look at so much data as humans!

I mean, software can calculate all of that for us automatically of course. But we won’t be able to verify, even by the eye, if the outcomes we obtained make any sense! After all, envelope of outcomes must be the best way to obscure mistakes in plain sight! They just “disappear” in the maze of everything.

This leads to a situation where one can ask:

How many load combinations is too much for proper structural steel design?

Of course, the code asks us to analyze all of them. However, the task seems pretty overwhelming. This usually leads to a situation where a lot of automatic verification is done. The engineer performing the analysis does not really take a look at any particular load combination.

They just look at the envelope of the outcomes and say, “This should be okay. The software did all the checks, so let’s move on.”

I feel that this is actually damaging to the quality of engineering design. And this is the problem I see with so much data and automation in analyzing it.

The curse of Load Combinations abundance

It can be proven that too much data leads to a situation where you know less than you think. And all of that while you’re absolutely certain that you know all that you need.

I actually encountered this on my own when I was doing a PhD. I wrote a script that generated a few thousand models of shell structures. It ran an analysis of those shells, and exported outcomes to beautifully formatted Excel sheets.

The result of this was over a month of calculations nonstop and hundreds of Excel files. Don’t get me wrong – the data was already beautifully formatted and ready to use…

… but I never got to it! The amount of data generated was so big that it felt overwhelmed. Sufficient to say that my PhD thesis does not include those results (at all!). Even though I spent a lot of time and effort to create them. It was just too much for me to go through!

This showed me that sometimes it’s simply better to analyze a few things deeply. Rather than creating hundreds of various combinations that change very little!

Not because there is something inherently wrong with having a lot of data…

but because you will most likely not have the time and energy to analyze all those outcomes one by one!

How Load Combinations were done in the past…

The problem with current codes is, that I think we try to change “engineering intuition” with “quantity of checks”. To search for the solution, let’s take a look at how it was done in the past.

Imagine that 40 years ago (I was 1 year old back then!), you wanted to analyze a steel structure. In some sense, everything was the same:

• You still would calculate the maximum wind load, maximum snow load, etc. Of course you would check a few different wind directions, maybe a few different snow distributions on the roof. And that was more or less it.

• Of course, if you wanted to be more accurate, you could use the reduction factors for the “secondary loads” to reduce them.

The difference is, you would quickly encounter an issue of “many load combinations”. If snow and wind are the only loads you have to take into account, this could still be manageable. Especially for simpler structures.

But oftentimes, you also have loads from machines, live loads, technology, and various other factors. Usually, every one of those comes with several flavors, distributions, or directions. If you consider all of that, you generate an insane amount of possible load combinations…

…an amount of load combinations you couldn’t really analyze manually!

Back in the old days, the reasonable approach to this was not to automate all of this.

Instead, you would use your engineering judgment to decide which loads were the most important for your structure. Of course, usually you couldn’t be sure. So you would pick 2-3 of the “worst loads” (instead of a single one).

This meant that only those would be the primary loads you would consider. Then you would wonder which loads “play well” with the primary loads. You know, decisions like which wind direction will be the worst with this load. On occasion you would exclude some loads from such combinations as they were “helping” (i.e. wind suction on the roof).

Finally, you would wonder which loads are “kind of independent”. In short, which loads impact separate elements in your structure, and don’t interact significantly in elements loaded by both. Those loads of course can be used as primary together… without much harm.

This kind of thinking had a strong base in practice:

You reduced the amount of load combinations you had to analyze!
Engineering judgment allowed to decide which combinations really are important, and which will not impact the design.

What I love about it so much, is the practicality of this. There were no automatic procedures that could handle hundreds upon hundreds of load combinations. So instead you used your judgement to reduce the load combinations to manageable number you could analyze yourself!

This meant that you tended to gravitate toward fewer load combinations. Simply to have a chance to deal with all of them. And this meant that you could actually analyze each one of those load combinations step by step.

Current approach to Load Combinations

Sadly, things have changed!

We do have automations that allow us to check hundreds of load combinations in a reasonable time.

But at the end of the process… all you can really do is display an envelope of outcomes. And hope for the best.

The issue is, that this approach disconnects you from the structure you’re analyzing.

If you would analyze a single load case, you know full well from which direction the wind blows, what is the snow distribution, and the distribution of other loads. So if your structure is deforming weirdly, you will instantly notice that. This gave you a chance to instantly react to modeling mistakes, as you were able to easily spot them.

This is completely impossible if you look at the envelope of all possible load combinations instead. You just see an enormous amount of deformation everywhere, in all directions at once. The only thing you can do is to think, ‘Well, somewhere in there are the correct deformations for all of the load cases I applied’! And you lose the possibility to actually find your mistakes.

Furthermore, by observing those single outcomes, you could gain some insights into how structure works! Things like how various loads impact things, how the load “spreads” through structures etc. This allows you to develop engineering intuition useful in future projects. Something that I feel we are missing nowadays.

I feel that along the way, we’re loosing something very important:

The ability to choose which loads will be the deciding ones in structures.

Instead we rely on checking “all possible combinations” simply because the worst one is among them… even if we don’t know which one is that.

I would argue that it’s actually better to analyze in-depth a few load combinations you choose, than automatically check the envelope from all of them! Even if you would fail to find the worst one, and you instead found the one 10% better.

Simply because, when you analyze only a few load combinations, you get a chance to understand your structure! You develop your engineering judgement further as well. But what is most important, you can spot big mistakes. And let’s face it…

10% won’t make your structure collapse, a big mistake you miss in the envelope may!

The art of the choice

I hope that I managed to convince you, that some critical thinking and good engineering judgement will get you a long way here.

But how do you establish which loads are important and which are not?

This is not an easy task, and it takes experience.

I feel that the best way to learn it is actually to model every load case. Note: I’m talking about single loads here. You know, like a single wind direction, or a specific snow distribution – not load combinations!

Then calculate the structure and see what the impact of each of the loads you applied. This is what you are looking at:

• Which elements were impacted, and to what degree

• For which elements this load is negligible or the impact is low

As you will quickly notice, usually it’s not a single load is the worst for entire structure. Usually one load can be most damaging to some elements, while other loads will be most damaging to other elements etc.

This of course means, that you have to treat all of those as “primary loads”. But the analysis doesn’t stop there.

You should also search for quite “independent” loads that mostly damage different elements. Those can be analyzed jointly as “primary” without a big impact on design (while reducing the amount of combinations needed).

I will admit that this is tiresome and difficult, especially at the start.

But on the other hand, I feel that this is critical to performing a reasonable design you have control over.

After all… automation will NOT think in your name!

On the more positive note, this may not be as difficult as it sounds!

My experience from industrial engineering shows that usually you have one huge dominating load. Be it machine load, live load, pressure or bulk solid/liquid loads. Usually one is “the most damaging one for most of the things”.

This makes selection a bit easier, and also put less pressure on the secondary load values. Simply because they may be insignificant compared to the main load. Which gives you an option to not reduce them, as not much will change in design.

But in the end, regardless of complexity of your model, the goal is the same:

Reducing the amount of load combinations you have to consider, gives you a chance to analyze the outcomes from each of those separately. This way, you ensure a more thorough and meaningful analysis, which ultimately leads to better and safer designs.

Just… don’t be a mindless rebel

I have to confess I’m always reluctant to write articles like this.

After all, there is a risk that some of my readers will simply start ignoring a lot of complexities of their designs because “Łukasz from the Internet told them so”…

This is totally NOT what I’m thinking about here. Actually, it’s exactly the opposite.

If you have the ability to select a few important load cases, you get a chance to better analyze those. And your structure as a direct result.

After all, there are a few critical things that can be done ONLY from the level of a single load combination (and not the envelope):

• Checking if my model behaves/deforms reasonably

• Checking if reaction forces match the applied loads

• Using Linear Buckling Analysis to establish buckling lengths, lateral torsional buckling parameters, impact of warping, etc.

Very often I get asked: “which load case should I use to do LBA and check stability of my structure?”. I usually reply, that you should check all of them, to be sure you haven’t missed something unexpected. And as you can imagine more often then not, the reply is: “I have to analyze all 600 of them?!?”.

And of course you don’t have to do that… you should have reduced that number to +/- 10 combinations. But you should really pay attention to those. In some designs it will be a bit more than 10, in some a bit less. But either way, it should be a “reasonably small number”.

When you have this – you can perform all of the advanced checks. And also think how your structure behaves, and understand if all is ok. To me, that part is the “true engineering”.

What about Code Compliance?

And here we are making a full loop (I love such topics!).

You see, nothing I wrote here, prevents you from following the code to the letter.

The only thing I’m advocating is:

STEP 1: Select a few critical load cases and analyze them deeply, so you know that everything works as it should. Check LBA for those and do all other things.

STEP 2: Generate all code load cases in the model you already checked and press “run overnight” button to be perfectly code compliant!

The only thing I ask you for, is not to rely only on STEP 2 above!

If you like, you can even switch them up! You can firstly generate all the combinations and run them (STEP 2). And after this is done select those few important ones to dive deeper (STEP 1).

This is not an approach I would take myself. It would bother me, that I would have to setup parameters for buckling, lateral torsional bucking etc. for code design, before doing LBA analysis (at least in more complex cases). But I can easily understand that some folks may like the reverse order of doing this.

There is nothing inherently wrong with that. The only downside would be if your LBA would show you something important. A thing that would force you to change code setup for stability verification. As this would force you to recalculate some of the things you already calculated.

Honestly, I don’t care which way you will approach it, as long as you will actually perform STEP 1. I understand you can decide that STEP 1 is completely enough for you. Or you may want to do STEP 2 as well. This is completely up to you and your engineering judgement.

Summary

I just had a talk on Nafems World Congress on a similar topic. During discussion someone from the audience asked me why do I resent “development”. The thing is… I absolutely don’t!

I’m absolutely fine with STEP 2. Heck, I’m happy that it’s automated, and you can crunch numbers automatically at high speed. Doing this by hand would most likely kill me.

That being said I strongly oppose the trend of performing “technical accounting”. A thing I understand as crunching a lot of numbers as an substitute for actually thinking about what you’re doing.

To me, this is simple:

Engineering is about looking in how things work, what is important, what impacts the design, and how you can deal with that.

In my head this is doable only if you limit the problem to manageable amount of possibilities – simply so you (as a human) have a chance to analyze each of them independently and deeply.

And when you do that. When you know that the structure you’re working on makes sense, and everything was set up ok – you’re fine! Automate the rest, and be happy that you don’t have to do it by hand! Just don’t think that automation will do this critical STEP 1 for you! It won’t!

This doesn’t of course stand “against” what current codes demand. Ironically it reduces the workload!

After all, codes would ask you to do this deep analysis for every load combination! This is of course humanly impossible. And this is used as an excuse to not doing this deep analysis at all! And this is NOT the way. You should do it – just reduce the task to manageable size first!

I feel it’s better to analyze a few load combinations first to see if all is good, and that you understand the problem properly. When you do, feel free to just run all those generated combinations.

The hilarious thing is, that I don’t think this is a “time saving” method at all!

I see how this could be seen as a time saving thing. After all you reduce the amount of load combinations significantly. You could potentially decide to only analyze those as well. That would be simply doing STEP 1 while ignoring STEP 2 I described. So obviously you would save on computing time and all that.

The thing is, that you will actually spend quite a bit of time on analyzing those few load combinations. After all, you will be doing LBA for them, analyze the outcomes and simply thinking about them. It will most likely take you longer to do that, than it would take the CPU to compute all code combinations in the first place! Especially since CPU can work overnight, and will not complain about that!

This is NOT to make things FASTER, it is to make us BETTER engineers and to make our designs BETTER. Most likely at the cost of some extra time and effort.

But I’m certain this extra time and effort is well worth it!