This article explains why structural engineers must always check load combinations manually. It draws on examples from practice, code logic, and project outcomes.
Structural engineers work with increasing speed and precision, relying heavily on design software to generate results. These tools run thousands of calculations in seconds, offering convenience that once required weeks of manual effort. But this efficiency can sometimes lead to complacency—especially when it comes to load combinations. While software appears to automate these checks flawlessly, it often masks the very engineering decisions that must remain in human hands.
Many engineers assume that once a structural model is analysed, all relevant combinations are covered. They click ‘run,’ review the worst-case envelope, and accept the outputs. However, codes such as Eurocode or ASCE do not just prescribe numbers—they embed intent, assumptions, and limitations. These nuances cannot always be captured by default settings or rigid algorithms. By blindly trusting software-generated combinations, engineers may overlook critical cases, load interactions, or construction-stage sequences that software cannot anticipate.
This article explains why structural engineers must always check load combinations manually. It draws on examples from practice, code logic, and project outcomes. While software remains a vital tool, engineering judgement must govern which combinations matter, which are missing, and which demand deeper consideration. Design must remain a controlled act of reasoning—not just data generation.
Understanding the Role of Load Combinations
Structural systems must withstand not one load, but many loads acting together. Dead, live, wind, snow, thermal, and accidental loads must be combined to reflect possible conditions. Load combinations ensure that a structure remains safe under every realistic scenario. Design codes provide combination rules to capture these possibilities. In Eurocode, for example, expression (6.10) and others under EN 1990 define how to combine variable and permanent actions using partial factors.
These combinations provide more than arithmetic rules. They reflect how different types of loads may or may not act simultaneously. For example, live loads and snow loads do not always peak together. Wind may reduce snow accumulation, or imposed loads may vary with occupancy. Load combinations reflect these statistical improbabilities. Thus, design codes introduce ψ-factors to reduce the intensity of variable loads in combinations. Software packages attempt to automate these formulations. But their algorithms may not always interpret load cases correctly or apply every clause correctly—especially in complex models or regional code adaptations.
The Illusion of Completeness in Software
Most design software promises to generate all necessary load combinations automatically. Many allow you to define basic load cases—then use code templates to build the combinations. These programs apply default partial factors, reduce variable actions using ψ-factors, and combine loads for ultimate and serviceability limit states. However, problems often arise from four areas: user input, program limitations, code interpretation, and construction logic.
User input errors are common. If a wind load is assigned as “live” instead of “wind,” the software may assign incorrect factors. If variable loads are not grouped correctly, the program may create duplicate or invalid combinations. Also, many programs have built-in limits on the number of combinations for performance reasons. They may neglect rare combinations or assign default ψ-values not applicable to local interpretations of the code. Even when combinations appear complete, they may omit physically relevant cases.
For instance, software may not model asymmetric live loading correctly across spans. It may assume balanced occupancy when, in reality, partial loading governs. It may neglect sequences such as progressive loading, temporary unbraced stages, or time-dependent interaction. A beam supporting a cantilever may experience its worst bending when the span is loaded but the cantilever is not. Such cases often fall outside automatic routines unless explicitly modelled.
Engineering Judgment Cannot Be Outsourced
Structural design remains an act of controlled simplification. Engineers idealise systems, reduce behaviour to line models, and isolate cases that represent failure potentials. This act cannot be outsourced entirely to code or software. While load combination logic may appear codified, its application depends on context. A buried tank, for example, may not experience wind loads—but many programs apply wind automatically. A façade element may experience snow and wind from different orientations—but software may superimpose them unrealistically.
Manual checking ensures that combinations match the actual structural behaviour, not just software logic. Engineers must review not just what the software did, but also what it did not do. They must check that combinations respect physical limits, service states, rare events, and staging. They must ensure that uplift, sliding, or second-order effects are triggered where required.
For example, in mat foundation design, uplift from wind may govern only in rare cases. A software tool may dismiss it by envelope logic—but the engineer must check that foundation bearing pressure remains within soil capacity even in those scenarios. Without this review, hidden failure modes may go undetected.
Real Case: A Missed Load Combination
Consider the case of a multi-span floor slab modelled in standard software. The engineer defined dead, live, and partition loads correctly and allowed the program to generate ULS combinations. The program created envelope moments for the internal and external spans. The designer used these envelopes to size the reinforcement. During review, the checker found that the maximum sagging moment under partial loading on alternate spans had not been captured. The software had assumed full-span uniform loading for each variable case.
When the combination was manually generated—with live load applied only on alternate spans—the moment in the internal span exceeded the design moment by 22%. The program had not flagged this case because the logic used was average-based, not pattern-based. The engineer had to revise the reinforcement design and explain the oversight. This mistake could have gone unnoticed if the manual check had not occurred. Such cases are not rare. They highlight the need to apply engineering intent beyond computational logic.
When Software Misses the Construction Sequence
Another example involves a cantilevered slab in a hotel corridor. The structural model was run with permanent and variable loads combined per Eurocode. The engineer accepted the outputs and finalised design. During site supervision, a senior engineer requested staged load analysis. When checked manually, it was found that the structure experienced cracking during early loading phases due to construction sequence. The formwork removed one end support before other parts had gained strength. This sequence led to a reversal of moment direction, causing reinforcement to yield on the wrong face.
The software had modelled final conditions only. It ignored time-dependent behaviour and intermediate states. No staged analysis was considered. Had the manual review occurred earlier, it would have flagged a need for top reinforcement continuity or temporary supports. This situation illustrates that load combination is not just a final state problem. The path to the final state matters.
Codified Does Not Mean Comprehensive
Codes like Eurocode or ACI do not claim to cover every combination. Their guidance is generic, aimed at broad consistency. But structural engineering involves a spectrum of systems—shells, frames, cables, towers, slabs, and tanks. Each behaves differently under combinations. Codes cannot address all these systems with the same precision. Engineers must translate codified principles into real load scenarios based on structure type.
For example, windward and leeward effects may not act together on different surfaces. In tension structures, prestress may interact with wind-induced movement. In tanks or silos, pressure loads and settlement loads may not combine linearly. Yet software may combine them additively unless instructed otherwise. Codes provide a framework, but engineers must filter and adapt combinations manually to suit geometry, behaviour, and risk.
Simplification Can Hide Danger
Software output is neat. It gives envelopes, max/min values, and graphical plots. These outputs feel complete. But they often mask complex internal conditions. For instance, in frame design, max axial force may occur in one load case, while max moment occurs in another. If the design uses these separately, interaction could be underestimated. Most software struggles to detect combined maxima unless the interaction is directly checked. Engineers must generate and examine specific combinations where actions coincide.
Also, serviceability checks are often misapplied. Deflections under service loads depend on realistic combinations, not worst-case factored loads. Software may run SLS combinations mechanically, but only the engineer knows whether long-term deflections from creep or shrinkage should be included. If not checked, floors may sag excessively or partitions may crack,.
What Manual Checking Looks Like
Manual checking does not mean ignoring software. It means verifying and curating the combinations it generates. The process often includes:
- Reviewing code expressions and checking which combinations the software used
- Generating custom load cases based on pattern, sequence, or construction stage
- Checking reactions, moments, and deflections under these manual combinations
- Identifying combinations where physical or service limits govern
- Re-running select cases with modified logic to isolate worst-case conditions
In many cases, engineers create supplementary spreadsheets to model simplified beams, slabs, or walls. These models allow for direct manipulation of load patterns and help identify missing logic in the full model.
Responsibility Lies with the Engineer
Design software is a tool. It is not the designer. Codes assign responsibility to the engineer of record—not the program. If a structure fails, the presence of analysis software does not reduce liability. Courts and clients alike expect engineers to exercise judgment. If the software missed a case that the engineer failed to review, the burden lies on the professional.
Therefore, manual checking is not optional. It is a professional obligation. This is how engineers maintain control over their designs. It is also how they develop deeper understanding of structural behaviour—an understanding that cannot be replaced by automation.
Conclusion
Structural safety depends on realistic assessment of how loads act together. While software helps generate load combinations quickly, it cannot replace engineering judgment. Programs follow logic. Engineers understand behaviour. This distinction matters. Blind trust in auto-generated combinations can lead to overlooked failure modes, construction-stage problems, or code misinterpretation.
Also See: Maximizing the use of Structural Engineering Software – 7 Best Practices
Sources & Citations
- EN 1990: Eurocode – Basis of Structural Design
European Committee for Standardization (CEN). (2002). Eurocode: Basis of Structural Design (EN 1990). Brussels: CEN. - Structural Design from First Principles
Reynolds, T., & Steedman, J. (2019). Structural Design from First Principles (3rd ed.). Red Globe Press. - Why Software Can’t Replace Engineering Judgement
Institution of Structural Engineers. (2021). The Structural Engineer, 99(4), pp. 20–23.
https://www.istructe.org/resources
