> 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/live-loads-fea/live-load-cases-fea.md). # Live Load Cases \[FEA] A Live Load Case ties together the lane definitions and the roadway surfaces, and runs the influence-surface search that finds, for every response in the model, the vehicle and lane arrangement that maximizes it. Its results are therefore **envelopes**: each reported value is the worst case over all considered positions, and different values in the same report generally correspond to different vehicle positions. Live Load Cases **generate load** through the influence-surface machinery. They add nothing to stiffness or mass. {% hint style="warning" %} Live load results are enveloped maxima, not a single equilibrium state. Reactions will not sum to any one applied load, and a moment and a shear reported at the same section usually occur under different truck positions. Use the concurrent-force extraction facilities where a genuinely simultaneous set of actions is needed for a design check. {% endhint %} ## Properties **Multiple Presence Factors (MPF):** The factors applied according to how many lanes are loaded simultaneously, entered as a list — by default `[1.2, 1, 0.85, 0.65]` for one, two, three and four or more loaded lanes. *Engineering influence.* These account for the reducing probability that several lanes are simultaneously loaded to their design maximum. The value **greater than 1 for a single lane** is the one that surprises people: it exists because the design lane load is calibrated on multi-lane statistics, and a single loaded lane is more onerous per lane than the calibration assumes. Because of it, **single-lane loading frequently governs exterior girders** even though multi-lane loading produces more total load. Entering fewer factors than the number of lanes that can fit leaves the extra cases without a defined factor. Setting all factors to 1 removes the reduction and over-predicts multi-lane demand. **Maximize for Stress Range (Fatigue):** Whether the search maximizes stress **range** rather than peak effect. *Engineering influence.* Fatigue is driven by the range between maximum and minimum stress at a detail, not by the peak value, and the vehicle position that maximizes range is generally **not** the one that maximizes peak. Enabling this makes the search target the range, which is what a fatigue check requires. Using peak-effect results for a fatigue assessment misstates the range — sometimes substantially, particularly in continuous structures where a detail sees both sagging and hogging. Note that fatigue is normally assessed with a single fatigue truck, no multiple presence factor and a reduced impact factor, so the lane and vehicle definitions used for a fatigue case usually differ from those used for strength. **Maximum # of Lanes:** A cap on the number of simultaneously loaded lanes. A value of −1 means no cap beyond what the roadway geometry allows. *Engineering influence.* Restricting this reduces the multi-lane cases considered, which understates demand on interior girders and substructure. It is legitimate where the physical roadway genuinely cannot carry more lanes, and unconservative if used to shorten run time. ## Lanes **Design Lane Option 1–4:** The lane definitions available to this case. *Engineering influence.* These are **alternatives** — the analysis considers each lane configuration and takes the governing result. Providing several allows different lane widths or vehicle mixes to compete, which is how a permit case and a standard case can be evaluated in one run. A case with no lane assigned has nothing to place and produces no live load at all. ## Roadways **Influence Path 1–4:** The influence surfaces or influence lines the lanes are placed on. A beam-line model attaches an influence line here exactly as a deck model attaches an influence surface — both are authored as the same object, distinguished only by whether its Loaded Group holds FELines or FESurfaces. *Engineering influence.* The loading surface defines the **available roadway width and extent** — the region vehicles may occupy. It therefore governs how many lanes fit and how far transversely they can shift, which feeds directly into the multiple presence factors and the exterior girder result. A surface narrower than the real roadway understates the number of lanes; one that extends over regions traffic cannot reach (a sidewalk, beyond a barrier) places vehicles where they never go and over-predicts local effects. A case with no influence path assigned produces no live load, silently. A case whose assigned path cannot place any load (no loaded group, no loadable elements in it, a zero-width path, or an all-zero unit load) stops the analysis with a message naming the cause. ## Magnification Factors **Magnification Factor Fx / Fy / Fz / Mx / My / Mz (Pos)** and the matching **(Neg)** columns: separate multipliers applied to each force and moment component, for positive and negative effects independently. *Engineering influence.* Live-load effects are enveloped, so a given component has both a maximum (positive) and a minimum (negative) extreme, and codes do not always factor the two identically — uplift and reversal cases in particular are often treated differently from the governing positive effect. Twelve separate factors let each extreme be scaled on its own. The factors scale the reported effect linearly. A value of **1** leaves a component unchanged, which is the normal setting; **0** suppresses that component's contribution entirely, which is a silent way to lose a design action if set by mistake. Because positive and negative are independent, setting only the Pos column leaves the negative extreme unfactored — a common oversight when a code factor is meant to apply to both senses. These are applied at result time and do not change where vehicles are placed. ## Settings **Structure Group:** The part of the structure active for this case. Leave empty to analyse the whole model. Restricting it also restricts which members the influence surface is built for. **Is Active:** Whether the case is solved. Inactive cases are skipped silently, so a live-load case that appears to produce nothing is worth checking here first. ## Verification * Confirm the case produced results at all. Zero live load usually means no lane or no loading surface is assigned, or the case is inactive. * Check the number of lanes the analysis placed against the roadway width and code lane width. * Compare a simple span's maximum live-load moment against a published table or a hand calculation for the design vehicle at its critical position. * Check that exterior girder results are governed by the single-lane case with its higher multiple presence factor, and interior girders by multi-lane — if not, look at the lane placement constraints. * Confirm the governing vehicle position is physically plausible by displaying it. * For fatigue, confirm the stress-range option is on and that the fatigue vehicle, impact and presence factors are the ones the code prescribes. * Do not check equilibrium against reactions; enveloped results are not in equilibrium. ## Common mistakes * **No loading surface or no design lane assigned**, so the case produces nothing. * **Using peak-effect results for a fatigue check** instead of enabling stress-range maximization. * **Setting all multiple presence factors to 1**, removing the reduction and over-predicting multi-lane demand — while also losing the 1.2 single-lane amplification that often governs exterior girders. * **A loading surface that extends beyond the trafficked width**, placing vehicles on sidewalks or past barriers. * **Capping the number of lanes** to shorten run time, understating interior girder and substructure demand. * **Treating enveloped results as a simultaneous load state** and trying to check equilibrium or combine components that never coexist. * **Reusing the strength case's lanes and vehicles for fatigue**, where a different vehicle, impact and presence treatment apply. --- # 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/live-loads-fea/live-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.