> 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/result-combinations-fea/combinations-envelopes-fea.md). # Combinations & Envelopes \[FEA] A Combination assembles the results of several analysis cases into one set. It serves several distinct purposes: **factoring and summing** cases into a design load combination, taking an **envelope** of cases where the governing one varies by location, **filtering** staged-construction results by load type, and extracting **incremental** versus **cumulative** results from a staged analysis. Combinations are **result-time post-processing**. They re-analyse nothing; they arithmetically combine results that already exist. {% hint style="warning" %} Combination is valid because linear results superpose. **Nonlinear case results do not superpose** — a nonlinear analysis's response to two loads together is not the sum of its responses to each. Combining nonlinear cases arithmetically produces a number with no physical meaning, and nothing prevents it. Where nonlinearity matters, apply the combined loading within a single nonlinear case instead. {% endhint %} ## Items The cases and their factors are edited in the combination's own item rows — see [Combination Items](/templates/openbrimfea/result-combinations-fea/combination-items-fea.md). The four settings below control **how** those items are combined. **Envelope:** Whether the result is the envelope of the items rather than their sum. *Engineering influence.* This is the fundamental behavioural switch on the object. * **Off (sum):** the items are factored and **added**. This is a design load combination — dead plus live plus wind, each at its own factor — and it produces one result that is the algebraic total. * **On (envelope):** the items are treated as **alternatives**, and for each response the most severe is reported. This is how "the worst of these load cases" is expressed, and it is what you want when different cases govern at different locations. Getting this backwards is consequential and quiet: enveloping cases that should have been summed under-predicts, because you get the largest single contribution instead of the total. Summing cases that should have been enveloped over-predicts by adding conditions that cannot coexist — several mutually exclusive wind directions, say. An enveloped result, like a live-load result, is **not a single equilibrium state**: its maximum and minimum at different locations occur under different constituent cases, so reactions will not balance against any one applied load. **Extreme Effects:** Whether both the maximum and minimum extremes are retained rather than a single value. *Engineering influence.* Many design checks need both ends of the range — maximum and minimum axial force with the corresponding moment, or the full range for a fatigue check. Retaining extremes gives a max/min pair per response rather than one number. Without it, a check that needs the minimum (uplift at a bearing, minimum compression in a prestressed section) has nothing to read. **Incremental:** Whether staged results are reported as the increment added by each stage rather than the cumulative total to that point. *Engineering influence.* In staged construction the two answer different questions. **Cumulative** results give the total force in a member at a point in the sequence, which is what a stress check needs. **Incremental** results give what a particular stage contributed, which is what you need to attribute force to a construction operation, to check the effect of one erection step, or to see how much creep redistributed between two stages. Reading incremental values as if they were cumulative badly understates the force present in a member, since it omits everything locked in beforehand. **Load Type Filter:** Restricts the combination to cases of a given load type. *Engineering influence.* Lets one combination pick up, for example, only the dead-load contributions across a staged sequence, without listing every stage individually. It relies on the cases being classified correctly — a case whose Load Type is wrong is silently excluded from, or wrongly included in, the filtered result. The filter is a convenience over explicit item lists, and explicit lists are easier to audit when a combination must be defensible. {% hint style="info" %} The 20 case/factor slots are spread across four tabs: the first five sit alongside the settings on **Items**, and the rest on **Cases 6-10**, **Cases 11-15** and **Cases 16-20**. For anything beyond a handful of contributions the [Combination Items](/templates/openbrimfea/result-combinations-fea/combination-items-fea.md) sheet is easier to work with and to audit — it lists each case-and-factor pair as its own row, with no 20-slot ceiling. {% endhint %} ## Cases 6-10 ## Cases 11-15 ## Cases 16-20 The remaining fifteen case/factor slots, five per tab. They behave exactly like the first five on the **Items** tab — each is a case and the factor applied to it — and are split across tabs only because twenty pairs do not fit on one. *Engineering influence.* Nothing about a slot's tab changes its meaning: slot 17 contributes exactly as slot 2 does. The split does make a long combination hard to review, because the contributions are spread across four tabs with no total shown anywhere — which is the main argument for using [Combination Items](/templates/openbrimfea/result-combinations-fea/combination-items-fea.md) instead once a combination has more than a few contributions. A slot left with a case but a zero factor contributes nothing, and on these overflow tabs that is especially easy to miss. ## Verification * Hand-check one combination: take the constituent case results at a known location, apply the factors, and confirm the combined value matches. This validates both the factors and the sum/envelope setting. * Confirm the Envelope switch matches intent — a summed combination should exceed every constituent, an enveloped one should equal the largest. * Check that every case you expect is actually included, especially when using the Load Type filter. * For staged results, confirm whether you are reading incremental or cumulative values by comparing a member's reported force against the sum of the stage increments. * Confirm no nonlinear case is being superposed. * Where minimum effects matter, confirm Extreme Effects is enabled and that minima are reported. * Do not check equilibrium on an enveloped combination; it is not a single load state. ## Common mistakes * **Envelope on where a sum was intended**, under-predicting by reporting the largest single contribution rather than the total. * **Summing mutually exclusive cases** — several wind directions, or several live-load positions — which cannot coexist. * **Superposing nonlinear case results**, producing a physically meaningless number. * **Reading incremental staged results as cumulative**, omitting all previously locked-in force. * **Relying on the Load Type filter** while some cases are classified wrongly, silently including or excluding contributions. * **Omitting Extreme Effects** and then having no minimum available for an uplift or fatigue check. * **Treating an enveloped result as an equilibrium state** and trying to balance reactions against it. * **A combination referencing an inactive case**, which contributes nothing without warning. --- # 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/result-combinations-fea/combinations-envelopes-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.