Envelopes
Extracting the governing value across dozens of combinations without reading every one — and the traps in doing so.
Loads & combinations 3 min read
An envelope is the extreme of a result quantity across every load state a combination can take, evaluated position by position. It answers "what is the worst sagging moment anywhere along this beam, under any ULS combination" without you opening forty result views.
What an envelope contains
At every position, for the chosen quantity, the envelope stores:
- the maximum and its governing combination,
- the minimum and its governing combination.
Both matter. A beam's maximum sagging and maximum hogging moments usually come from different combinations, and a member checked only against the maximum is unchecked in the other direction.
Where envelopes come from
A combination has one of three kinds, and two of them are envelopes:
| Kind | What it produces |
|---|---|
| Linear | One load state: every included case at its factor |
| Envelope | A set of states: each included case acts or not, as its load group allows, and the result is the min and max over the set |
| Code | The permutations EN 1990 or ASCE 7 write for the load groups, and the min and max over them |
So a code-generated ULS combination is already an envelope, over all the permutations of leading and accompanying actions with the favourable and unfavourable factors. An envelope you write by hand does the same over the cases you include: a case in an exclusive group is one of the alternatives, a permanent case is always in. Each permutation is a factored sum of the case results, and the envelope is the min and max over all of them.
The quantity is not a property of the envelope. Pick the combination in the viewport or the result table and switch between , , , deflection or a reaction as you would for any other combination.
Keep ULS and SLS envelopes separate. They serve different checks, and mixing them produces a number that means nothing.
The trap: envelopes are not equilibrium states
An envelope is an assembly of extremes from different combinations. The set of values along a member is not a state the structure was ever in.
Consequences:
- Never use envelope values together in a hand calculation as if they were simultaneous. The maximum moment and the maximum axial force in a column typically come from different combinations; designing for both at once is not even safe in general — a reinforced concrete section can carry more moment under more compression — and it is not what the interaction clauses intend.
- Interaction checks need a combination, not an envelope. An axial–bending interaction must be evaluated combination by combination, with the values that actually occurred together. The design checks do this internally, which is why the governing combination they report may not be the one that produced the peak moment.
- A reaction envelope does not sum to the applied load of any single case. Foundation design still needs the per-combination values.
Using envelopes well
| Task | Envelope? |
|---|---|
| Sizing reinforcement in a slab strip | Yes, of the Wood–Armer design moments — not of , and enveloped separately |
| Selecting a steel section for bending only | Yes, as a first pass |
| Steel member with axial and bending | No: per-combination interaction |
| Foundation design | No: per-combination reactions |
| Deflection check | Yes, on the right SLS combination set |
| Reporting the governing case | Yes, provided you report the combination too |
Reporting
An envelope value on its own is not reviewable. Always carry the governing combination with it. The result tables and the exported report do this by default; keep the pairing when you copy numbers into a spreadsheet or a hand calculation.
Related
Automatic combinations for the permutations a code combination envelopes over, Load cases for the groups that decide which cases are alternatives, and Result tables for extracting the numbers.
Something wrong or unclear on this page? Tell us, and it gets corrected.