> 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/concurrent-forcedisplacement-requests.md). # Concurrent Force/Displacement Requests A Concurrent Force/Displacement Request answers a question that enveloped results cannot: **"when *****this***** quantity is at its worst, what is *****that***** quantity doing at the same instant?"** Envelopes report each response at its own maximum, under whatever load position produced it. Those maxima do not occur together. But many design checks need a genuinely simultaneous set — a column's axial force *at the moment* its moment peaks, or a bearing's vertical reaction *at the moment* the horizontal one peaks. This object performs that concurrent extraction. It is a **reporting** object. It changes no analysis result; it selects and reports existing ones. {% hint style="info" %} Reading an enveloped maximum axial force alongside an enveloped maximum moment and checking them together is usually **conservative but sometimes wrong** — for an interaction check, the critical combination may be a lower axial force with a higher moment, which the envelope pairing never produces. This object is how the correct pairing is obtained. {% endhint %} ## Data **Maximize For:** The direction or component that is driven to its extreme. The available directions follow the axes of the chosen Maximized Element Result Type. *Engineering influence.* This defines the **search criterion** — the quantity whose extreme selects the load position. Everything else in the request is reported *at that position*. Choosing the wrong criterion means reporting concurrent values at the wrong instant, and the results will look perfectly reasonable. **Maximized Element:** The element whose response is driven to its extreme. **Maximized Element Result Type:** Which result on that element is maximized — an end force, a displacement, a stress component. **Maximized Node:** Which node of the maximized element the result is taken at. **Maximized Position:** The position along the maximized element the result is taken at. *Engineering influence, these four together.* They form the address of the **driving** quantity. They must be mutually consistent: a nodal result needs a node, an element result at a position needs the position. A combination that does not resolve produces no result rather than an error message, so an empty request is far more often an address problem than a genuinely zero response. The position matters because a member's critical section is often not at its ends — the maximum moment in a loaded span is somewhere in the middle, and driving on an end force will select a different load position entirely. **Result Element:** The element whose response is **reported** at the driving position. **Result Element Result Type:** Which result is reported. **Result Node:** Which node of the result element the value is taken at. **Result Position:** The position along the result element the value is taken at. *Engineering influence, these four together.* They form the address of the **reported** quantity. The key point is that the result element need not be the same as the maximized element: you can drive on a deck displacement and report a pier base moment, which is exactly how you find the substructure demand that accompanies the critical superstructure condition. Reporting the *same* element and result type as the maximized one simply returns the envelope value, which is a useful check that the request is wired up correctly but tells you nothing new. **Result Unit Category (Readonly):** Reports the unit category of the quantity being extracted. Use it to confirm the result type you selected is the one you meant — a mismatch between the expected and displayed unit category is the quickest sign that the result address is wrong. {% hint style="warning" %} This column is derived and cannot be edited, but it is not flagged read-only, so typing into it appears to work and the value is discarded on redraw. {% endhint %} ## Verification * Set the result address equal to the maximized address and confirm the reported value matches the envelope maximum. This proves the request resolves before you rely on a cross-element extraction. * Confirm the request returns a value at all; nothing usually means an inconsistent address rather than a zero response. * Check the Result Unit Category matches the quantity you expect. * Compare the concurrent value against the enveloped value for the same quantity. The concurrent value must be **less than or equal to** the envelope; if it is larger, the addresses are not what you think. * For an interaction check, compare the concurrent pairing against the enveloped pairing and confirm which is more critical — they are frequently different. * Confirm the driving position is at the member's critical section rather than an arbitrary end. ## Common mistakes * **Using enveloped maxima together for an interaction check**, pairing values that never coexist — the problem this object exists to solve. * **An inconsistent result address** (element/node/position/result type), producing no output and no explanation. * **Driving on the wrong quantity**, so concurrent values are reported at the wrong instant while looking entirely plausible. * **Driving on an element end** when the critical section is mid-span. * **Assuming the concurrent value is conservative.** It is the *actual* simultaneous value, which for an interaction check may be more critical than the enveloped pairing, not less. * **Forgetting that live-load and enveloped results are position-dependent**, and comparing a concurrent extraction against an envelope as though the difference were an error. --- # 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/concurrent-forcedisplacement-requests.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.