> For the complete documentation index, see [llms.txt](https://docs.openbrim.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openbrim.org/templates/openbrimfea/loads-fea/static-loads-fea/load-cases-fea.md). # Load Cases \[FEA] A Load Case is one distinct loading condition — dead load, wearing surface, a construction operation, a wind event — and it is the container every static load belongs to. Loads point at a case; the case is solved; results are reported per case and then combined. The case is also where **self-weight** is switched on and where the **solution method** (linear or nonlinear) for that condition is chosen. A Load Case does not itself apply anything to the structure except self-weight. It **generates load** through its weight factors, and it **controls the solution** through its nonlinear settings. ## Self Weight **Weight Factor X / Y / Z:** Multipliers applied to the structure's own self-weight in each global direction, computed from element volume and material density. *Engineering influence.* This is how gravity enters the model. In a model with Z vertical and downward gravity, a dead-load case normally uses **Weight Factor Z = −1**; the sign must match the model's orientation, and getting it wrong applies gravity upward, which produces a plausible-looking deflected shape in the wrong direction. A factor of **0 in every direction means no self-weight at all** in this case — the correct setting for a superimposed-load case, and the single most common reason a dead-load case reports far less load than expected. Values other than ±1 scale self-weight, which is how a load factor can be baked into the case, though it is usually cleaner to apply factors in the combination instead. Only elements that are **active** in this case contribute — see Structure Group and construction staging. Results sensitive to it: everything in a gravity-dominated structure; reactions are the quickest check. **Load Type:** Classifies what kind of load the case represents, for use by combinations and design code checks. *Engineering influence.* This is a **classification** parameter, not a physical one — it does not change the analysis. It matters because design code checks and automated combinations select cases by type, so a case classified wrongly may be omitted from a combination that should include it, or factored with the wrong partial factor. The error surfaces in design results, not in analysis results. ## Nonlinear **Nonlinear:** Whether the case is solved with a nonlinear (incremental, iterative) solution rather than a single linear solve. *Engineering influence.* This is the master switch that decides whether the model's nonlinear ingredients are actually honoured. **Gaps, one-sided springs, tension-only and compression-only members, cables and geometric (P-delta) stiffness are all ignored in a linear case** — the model is linearized and solves as if those features were ordinary linear elements. A cable-stayed or gap-supported structure analysed linearly can therefore show stays in compression and shear keys carrying tension, with no warning at all. Turning it on costs solution time and introduces convergence risk. Turn it on when the model contains nonlinear features whose behaviour matters, or when large-displacement effects are significant; leave it off for an ordinary linear structure, where it adds cost without changing the answer. Note that results from nonlinear cases cannot be superposed the way linear results can, which constrains how they may legitimately be used in combinations. **# of Steps:** The number of load increments the total load is applied in. *Engineering influence.* Applying load in more steps follows the structure's changing stiffness more closely and generally improves convergence and accuracy for a strongly nonlinear problem. A single step is fine for a mildly nonlinear case and often fails to converge for one with gapping or large displacement. Increasing steps increases run time roughly proportionally. It has no effect on a linear case. If a nonlinear case fails to converge, increasing this is usually the first thing to try. **Maximum # of Iterations:** The iteration limit within each load step. *Engineering influence.* Bounds the effort spent trying to satisfy equilibrium in a step before the solver gives up. Raising it lets a slowly-converging step succeed; it also allows a genuinely divergent problem to waste a lot of time before failing. A converged solution is not more accurate for having been given more iterations — the tolerances below define accuracy, this only defines patience. **Force Tolerance:** The out-of-balance force below which a step is accepted as converged. **Displacement Tolerance:** The displacement change below which a step is accepted as converged. *Engineering influence, both.* These define what "solved" means. Loosening them makes convergence easier and the answer less accurate — an out-of-balance force left in the model is a real force the structure never received. Tightening them improves equilibrium and may prevent convergence entirely. Set them relative to the magnitudes in your model: a force tolerance of 1 is meaningful in a model whose reactions are thousands and meaningless in one whose reactions are single digits. Both defaults are absolute values, so a model built in different units needs them reviewed. ## Settings **Structure Group:** The part of the structure active in this case. *Engineering influence.* Restricting a case to a group analyses a partial structure — a construction condition where only part of the bridge exists, or a check on a subassembly. Elements outside the group are absent, and self-weight is only generated for elements inside it. Leave empty to analyse the whole structure. A group that resolves to nothing produces a case with no structure at all. **Is Active:** Whether the case is solved. *Engineering influence.* Inactive cases are skipped silently, which is convenient for keeping a large suite of cases in one project and running a subset — and is a frequent reason a case appears to produce no results. Any combination referencing an inactive case will be missing that contribution. ## Verification * Check reactions against a hand calculation of total applied load. For a dead-load case, the vertical reaction total must equal the structure's weight. * Confirm the deflected shape points the right way; an upward dead-load deflection means the weight factor sign is wrong. * For a superimposed case, confirm the weight factors are zero so self-weight is not double-counted with the dead-load case. * Compare a nonlinear case against its linear equivalent. A large difference tells you the nonlinearity matters; no difference at all suggests the nonlinear features are not actually engaging. * For a nonlinear case, confirm it reported convergence rather than hitting the iteration limit, and check that the out-of-balance force is small relative to applied load. * Re-run with more steps and confirm the answer is stable. * Check that the case is Active and that every combination referencing it includes it. ## Common mistakes * **Weight factors left at zero in the dead-load case**, so the structure weighs nothing. * **Weight factor applied in the wrong direction or sign**, applying gravity sideways or upward. * **Self-weight switched on in more than one case**, double-counting dead load through the combinations. * **Running a model with cables, gaps or one-sided members as a linear case**, where all of those features are silently ignored. * **Loosening tolerances to force convergence** and accepting a solution with meaningful residual out-of-balance force. * **Tolerances left at their defaults in a model whose units make them meaningless** — either unreachably tight or trivially loose. * **Leaving a case inactive** and not noticing that a combination is short a contribution. * **Superposing nonlinear case results** in a combination as if they were linear. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.openbrim.org/templates/openbrimfea/loads-fea/static-loads-fea/load-cases-fea.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.