Skip to content

Loads & combinations

Build load cases, generate code combinations automatically and find out which one actually governs.

Loads & combinations 1 min read

Loading is where most of the engineering judgement in a linear model lives. The solver combines whatever you give it; deciding what belongs in each case, and which cases can act together, is yours.

In this section

The structure of a loaded model

Load case          a single, self-consistent action (e.g. "Imposed — offices")
    ↓
Load group         cases that share a factor and a relationship (leading/accompanying)
    ↓
Combination        factored sum of cases, one per code equation and leading action
    ↓
Envelope           the extreme of a result quantity across a set of combinations

Keep load cases pure. A case called "Dead + services" cannot later be factored separately from the dead load it contains, and you find that out at the worst moment: when the check fails and you need to know which part drove it.

Linearity, and what it buys you

Linear static analysis superposes. The solver solves each load case once and builds every combination as a factored sum of those results, which is why fifty combinations cost little more than one.

Common mistakes

  • Self-weight counted twice: once by the automatic self-weight case and once in a manually applied dead load.
  • Imposed load applied everywhere at once when the governing arrangement is a chequerboard pattern. Adjacent-span loading usually governs support moments.
  • Wind treated as a single case when the code needs several directions and internal pressure coefficients.
  • Combinations generated once and never regenerated after new cases were added. The combination set does not update itself silently; regenerate it and confirm the count.

Something wrong or unclear on this page? Tell us, and it gets corrected.