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.