> 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/parameters-fea.md). # Parameters \[FEA] A Parameter is a named global value that other objects' parameters can reference by name. Changing it updates everything derived from it, which is what makes a model **parametric** rather than a fixed set of coordinates. This is the mechanism that replaces manual coordinate editing: define `SpanLength` once, express the support positions as `SpanLength` and `2*SpanLength`, and changing the span moves the supports, the girders and everything positioned from them together. Parameters are **definitions**. They add no stiffness, mass or load — but because other parameters resolve through them, a change here propagates into geometry, properties and loads throughout the model. ## Parameter **Parameter Name:** The name used to reference this parameter from other cells and equations. *Engineering influence.* The name is the **reference**, so it is effectively an identifier in a small programming language. Any cell in any spreadsheet can use it in an expression, and OpenBrIM propagates renames to references automatically — but a name that collides with something else in scope, or that is too generic to be unambiguous (`L`, `W`, `Length`), makes expressions hard to read and easy to get wrong months later. Give parameters names that say what they are (`SpanLength`, `GirderSpacing`, `DeckThickness`). The readability of every expression that uses them depends on it. **Parameter Value:** The value the name resolves to. *Engineering influence.* Everything referencing the parameter recomputes when this changes, which is the point — and also the risk. A single edit can move a large part of the model, so the consequences extend well beyond the cell being edited. Before changing a parameter, it is worth knowing what depends on it. Values participate in expressions, so a parameter can be defined in terms of others (`DeckWidth = GirderSpacing * (NumGirders - 1) + 2*Overhang`). Chains like this are powerful and should stay shallow enough to follow; deep chains make it hard to predict what a change will do, and circular references cannot resolve at all. The value carries a **unit**, taken from where it is used. A parameter used as a length in one place and a dimensionless factor in another is a source of confusion that no error message will flag. **Unit Label (readonly):** Displays the unit associated with the parameter. *Engineering influence.* Output, and the quickest way to confirm a parameter is being interpreted as the quantity you intend. A parameter you think of as a length that reports no unit is not being used the way you expect, and its value may be entering expressions in the wrong scale. ## Verification * Change a parameter and confirm everything that should move does, in the 3D view. Anything that stays put is not actually referencing it. * Check the **Unit Label** matches the quantity you intend. * After a parametric change, re-run the analysis and confirm the model is still valid — parametric updates can produce degenerate geometry (zero-length members, inverted elements) at extreme values. * Confirm no circular references exist by checking the model compiles. * Search the model for the parameter name to establish what depends on it before changing it. * Sanity-check derived parameters by evaluating their expressions by hand for one set of inputs. ## Common mistakes * **Generic names** (`L`, `X`, `Value`) that make expressions unreadable and encourage the wrong reference being used. * **Changing a parameter without knowing what depends on it**, moving parts of the model unnoticed. * **Deep or circular dependency chains**, which are hard to predict and, when circular, cannot resolve. * **Reusing one parameter for two physically different quantities** that happen to share a value — they will diverge eventually, and the model will be wrong in one of the two places. * **Assuming a parametric change is safe** without re-running the analysis; extreme values can produce degenerate geometry. * **Hard-coding a value in one place** that should have referenced the parameter, so it silently fails to update with everything else. --- # 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/parameters-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.