> 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/staged-construction-fea/changes-fea.md).

# Changes \[FEA]

A Change modifies an object's property **at a specific construction stage**, so that the structure's properties evolve through the erection sequence rather than staying fixed.

This is how the events that are not simply "an element appears" are modelled: releasing a temporary support, locking a bearing that was free during erection, switching a section from uncracked to cracked, or changing a spring stiffness when falsework is struck.

Changes use the same underlying object as **Analysis Overrides** — the difference is context. An Analysis Override scopes a property change to an *analysis case*; a Change scopes it to a *stage* in the construction sequence, and because stages inherit from one another, the change **persists into every subsequent stage** unless it is changed again.

Changes modify the **stiffness matrix** (or whatever property they target). They generate no load and add no mass.

{% hint style="warning" %}
A Change persists forward through the stage chain. Releasing a support in stage 3 leaves it released in stages 4, 5 and 6, and in the final permanent state, unless a later Change restores it. Temporary conditions therefore need **two** entries — one to apply them and one to reverse them.
{% endhint %}

## Data

**Analysis Case:** The stage's case that the change applies from.

*Engineering influence.* This is what places the change in the sequence. Applying it a stage too early or too late changes which loads are carried by which configuration — releasing falsework before the structure can span produces a collapse mechanism, and releasing it after subsequent load has been applied leaves that load carried by the falsework instead of the structure.

## Object / Property / Value

Each object type has its own tab — FENode, FESpring, FELine, FESurface, FEVolume, and Custom — and each carries the same trio of fields. Edit on the tab matching the type of object you are changing.

**Object:** The object whose property changes.

**Property:** The property being changed.

**Value:** The value it takes from this stage onward.

*Engineering influence, by object type.*

**FENode** changes are the most common in staged work: releasing or fixing a support. This is how falsework release, jacking operations, bearing installation and the transition from a temporary to a permanent support condition are modelled. Because it changes restraint, it redistributes the whole load path from that stage on — releasing a support transfers its reaction to the others, and the forces locked in before the release **stay** locked in.

The value follows the node's own sign convention: **0 free, negative fixed, positive a spring stiffness**. Entering 1 to "fix" a support produces an almost-free spring instead.

**FESpring** changes substitute a bearing or isolator stiffness — a bearing that is temporarily restrained during erection and released for service, or a stiffness that changes when a shear key is installed.

**FELine** and **FESurface** changes usually switch section properties: uncracked to cracked as the structure is loaded, or a stiffness modifier that reflects a change in the member's condition. Softening a member from a given stage sheds force from it into stiffer neighbours from that point on, while leaving everything locked in before the change untouched.

**FEVolume** changes apply the same idea to solid elements.

**Custom** handles any property not covered by the typed tabs. There is no type checking that the named property is meaningful for the selected object, so a name that does not resolve produces a change that silently does nothing.

## Verification

* Step through the stages and confirm the property changes at the intended stage — checking a support's reaction before and after a release is the clearest test.
* Confirm forces locked in before the change are retained afterwards; that retention is the point of staged analysis, not an error.
* After releasing a support, check that its reaction goes to zero and that the others increase to compensate, with the total unchanged.
* Confirm temporary conditions are reversed where intended — search for the paired Change entry.
* Compare the final stage's properties against the intended permanent condition; anything left changed from a temporary state will be wrong in the final structure.
* Run the sequence with and without the change to confirm it takes effect at all.

## Common mistakes

* **Forgetting the change persists forward**, leaving a temporary release or a locked bearing in the final permanent structure.
* **Applying the change one stage too early or too late**, so load is carried by the wrong configuration.
* **Using the node sign convention wrongly** — entering 1 to fix a support, which creates a nearly free spring.
* **Releasing falsework before the structure can span**, producing a mechanism.
* **Editing on the wrong tab** for the object type being changed.
* **A property name that does not resolve** on the Custom tab, producing no change and no warning.
* **Reviewing only the final stage** and missing that an intermediate configuration was never valid.


---

# 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/staged-construction-fea/changes-fea.md?ask=<question>&goal=<endgoal>
```

`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.