Understanding Load Cases and Load Combinations in STAAD.Pro

STAAD.Pro will run whatever load cases you type. That is the feature and the hazard. A load case is a labelled set of actions — self-weight, superimposed dead, live, wind in a direction, a crane scenario. A load combination is an assembly of those cases used for a check. Mixing them up, or copying another project’s combination list, produces tidy ratios for the wrong building.

This article explains the modelling discipline: naming, primary cases versus combinations, not leaving experimental cases in the issued set, and documenting what was run. It does not provide building-code equations, factors, or a universal combination recipe. Project-specific load combinations must follow the applicable design basis, project specifications and governing standards. Do not invent factors in STAAD or in Excel because a previous warehouse file already had them.

Geometry and properties can be perfect and the file still be unusable if the load list is folklore. Read this with model checking and output review. What STAAD.Pro is sets the wider context.

Load cases are a register, not a junk drawer

Name cases after the physical action and direction: dead, superimposed dead, live storage, wind on side A, crane with trolley left — whatever the project actually has. Numbers alone (“L3”) force everyone to decode. If the design basis lists occupancy live load as a distinct item, it should not be lumped into dead because the GUI made that easy.

Self-weight should be explicit. Missing self-weight is a classic STAAD embarrassment. Duplicate self-weight because a template already had it is the equally classic opposite. Check once, in the load list, not in a ratio plot.

Combinations are owned by the design basis

STAAD combination commands assemble cases. They do not know your standard. Someone has to type the assembly that the project documents require. That someone should be looking at the design basis, not at a screenshot from a forum and not at last year’s industrial shed in a different country.

Do not invent formulas

This guide will not list factor strings. If you need the combinations for a job, open the project specifications and the governing standard named there, and implement those. If they are not yet defined, stop modelling combinations and get them defined.

Templates are guilty until checked

A company template can be a starting list of case names. It is not permission to reuse factors. Delete combinations at job start and rebuild from this project’s basis, or tick through every line against the basis and sign that check.

How STAAD.Pro organisation choices affect mistakes

Primary load cases, repeat loads and combination definitions are easy to tangle. A repeat load that already includes a factor, later placed into a combination that factors it again, is a modelling error you will not see in the renderer. Keep a written map: which objects are raw actions, which objects are already factored assemblies.

Documenting loads so drawings and reactions stay honest

The load list should be readable on an analysis summary sheet: case name, what it includes, source (architecture, vendor data, assumption). If a superimposed dead load assumes a future solar array, say so. When reactions are issued, combination names on the table must be these names.

• Every issued combination appears in the design basis or a written project addendum.
• No leftover combinations from a copied file.
• Wind and seismic directionality match the architectural orientation you documented in coordinates.
• Construction-stage cases, if any, are labelled so they cannot be used for in-service foundations.
• Notional loads, if the basis requires them, are implemented as the basis states — not as a remembered percentage.
• A checker can regenerate the combination list from the basis without opening STAAD first.

Reviewing the load list before analysis is treated as final

Print the load case and combination list and read it like a drawing. Look for duplicate self-weight, empty cases, combinations that reference deleted cases, and names that do not match the basis. This is cheaper than arguing about a utilisation ratio that came from a junk combination.

If you will export geometry to CAD via Staad2CAD, remember that CAD will not carry the load list. The drawing notes must still cite the basis. Geometry conversion does not freeze loads; only the archived .STD and the notes do.

Building the STAAD load list from a design basis

Start from paper (or PDF), then software — never the reverse.

1. Obtain the design basis and any owner specifications that list combinations or special loads.
2. List physical actions actually present: dead, live, wind, snow or rain if applicable, crane, equipment, notional items the basis requires.
3. Create primary cases named after those actions; apply the loads; do not factor yet unless the basis stores a case that way.
4. Enter combinations exactly as the basis requires; do not add extras “for interest” in the issued list.
5. Prefix any trial cases so they cannot be selected in envelopes used for issue.
6. Print the load list and tick it against the basis with a checker.
7. Only then run analysis for issue and produce reactions from those combinations.
8. If the basis changes, edit cases and combinations and re-issue; do not patch factors in a spreadsheet of results.

Engineering tips

• Put the design-basis document name and revision in the STAAD file notes.
• If a vendor load arrives late, add a named case; do not bury it inside dead.
• Keep wind cases in building axes that match the drawing north arrow.
• Empty load cases should be deleted, not left “for later.”
• When two standards are mentioned in a confused brief, stop and get one basis; do not merge combination lists.
• A one-page load register in Excel is fine if it is controlled — see office Excel programs only as tables, not as shadow codes.

Load-list mistakes that analysis will happily run

Copying COMBINATION lines from another country’s job

Factors, case meanings and even which actions exist will be wrong. Rebuild from this basis.

Applying factored loads in primary cases and factoring again in combinations

The structure is being asked a question nobody meant. Keep raw actions raw.

A single case called “WIND” that includes all directions

You can no longer combine dead with one direction. Split directions.

Leaving TEST combinations in the envelope used for steel design

A 10× live-load trial will govern every member and nobody will know why.

Writing combination formulas in a blog, chat, or spreadsheet “because STAAD was slow”

If it is not in the design basis and the model, it is not the design. This article will not supply formulas to paste.

STAAD load-case checklist

Tick against the design basis document, not against memory.

• Design-basis revision is identified in the file.
• Self-weight appears once, on purpose.
• Each physical action has a named primary case.
• Direction-dependent actions are split by direction.
• Special loads (crane, equipment, tanks) are named and sourced.
• Combinations match the basis; extras are not in the issued list.
• No copied combinations from another project remain.
• Trial cases cannot enter issued envelopes.
• Combination names are usable on reaction tables and drawings.
• Checker has ticked the printed list.
• CAD notes cite the basis, not “loads as per STAAD.”

Frequently asked questions

What is the difference between a load case and a load combination in STAAD.Pro?

A load case holds applied actions you defined. A combination assembles cases for a check, using the rules from the project design basis. Results for issue generally come from those combinations, not from an unnamed pile of cases.

Can you give the load combination factors to type into STAAD?

No. This article will not invent or reproduce code equations. Use the combinations required by the applicable design basis, project specifications and governing standards for that job, implemented by the responsible engineer.

Should service and strength combinations both live in the same STAAD file?

They can, if the basis needs both and they are clearly named so they cannot be mixed in an envelope. Some teams keep them in clearly labelled groups. Clarity beats compactness.

Why do my STAAD combinations not match the PEB software combinations?

Because someone typed two different interpretations. Reconcile to one design basis. Do not average. See PEB engineering software and PEB column reactions.

The load list is part of the model’s geometry of meaning

STAAD.Pro load cases name the actions. Combinations assemble them only as the project design basis requires. Envelopes and repeat-load tricks are modelling tools, not a licence to invent factors. If the list cannot be ticked against a document, the analysis is not ready to issue.

Project-specific load combinations must follow the applicable design basis, project specifications and governing standards. Continue with model checking and output review. StruTools provides educational process, not code combinations and not a substitute for qualified design review.