> 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/coordinate-systems-fea/coor-sys-fea.md).

# Coor. Sys. \[FEA]

A Coordinate System defines a local reference frame — an origin and an orientation — that can be assigned to nodes and loads. Positions, restraint directions, applied load components and reported results are then expressed in that frame instead of the global one.

Its main structural purpose is **skewed and inclined boundary conditions**. A bearing on a skewed abutment is fixed along the bearing line and free across it; expressing that in global axes is impossible, because "global X" is neither of those directions. Assigning a rotated coordinate system makes the restraint directions match the physical ones.

A Coordinate System is a **reference definition**. It adds no stiffness, mass or load — but by reorienting restraints and loads it changes the analysis substantially.

{% hint style="warning" %}
Assigning a coordinate system to a node reinterprets **both** its coordinates and its restraint directions, and reports its displacements and reactions in that frame. A reaction that appears not to match a global hand-check is often correct but expressed in the local frame.
{% endhint %}

## Properties

**Origin X / Y / Z:** The position of the local frame's origin in global coordinates.

*Engineering influence.* Coordinates of anything assigned to this system are measured **from this point**. Moving the origin moves everything referenced to it, so an origin that is wrong shifts a whole family of nodes together — which is easy to miss because the structure keeps its shape while sitting in the wrong place.

The origin does **not** affect restraint directions; only the rotation does. For a skewed support where you only need the directions rotated, the origin can stay at the global origin.

## Euler

**Rotation Z / Rotation Y / Rotation X (ZYX order):** The orientation expressed as three sequential Euler rotations, applied in **Z, then Y, then X** order.

*Engineering influence.* This is the usual way to define orientation, and for the common case it is simple: a skewed abutment needs only **Rotation Z**, by the skew angle, so that the local X axis runs along the bearing line.

The **order matters**. Euler rotations do not commute — applying 30° about Z then 20° about Y gives a different frame from 20° about Y then 30° about Z. When more than one angle is non-zero, the resulting orientation is rarely what you would guess from the individual numbers, and it should be confirmed by displaying the axes rather than reasoned about.

The **sign convention** follows the right-hand rule about each axis. A skew entered with the wrong sign rotates the support the wrong way, which on a skewed bridge produces restraint across the bearing line where it should be along it — a plausible-looking model with the wrong load path.

Getting the rotation wrong does not produce an error. It produces reactions in directions the real bearing cannot deliver, and a structure that is restrained against thermal movement it should accommodate.

## Quaternion

**Quaternion x / y / z / w:** The orientation expressed as a quaternion.

*Engineering influence.* An alternative, order-independent representation of the same rotation, used mainly when the orientation comes from another system — a CAD package or an alignment computation — rather than being typed by hand. Quaternions avoid the gimbal-lock degeneracy that Euler angles suffer when the middle rotation approaches 90°, which is why they are preferred for programmatic definition.

A quaternion must be **normalized** (`x² + y² + z² + w² = 1`) to represent a pure rotation. An unnormalized quaternion — including the all-zero default — does not define a valid orientation, and a system left with all four at zero has no meaningful rotation. Use either the Euler fields or the quaternion fields, not both.

## Verification

* **Display the local axes** at a node assigned to the system and confirm they point along and across the bearing line. This is the only reliable check; the numbers alone are not interpretable, especially with multiple rotations.
* Apply a unit load along a local axis and confirm the structure moves in the expected physical direction.
* Check reactions at a skewed support: the restrained direction should carry reaction and the free direction should carry essentially none.
* Confirm a bridge with skewed supports is free to expand along its length under a temperature rise — if it is not, the restraint directions are probably wrong.
* Compare a node's global position against its local coordinates and the origin by hand.
* If using quaternions, confirm the four components are normalized.

## Common mistakes

* **Sign error on the skew angle**, restraining across the bearing line instead of along it.
* **Assuming Euler rotations commute** when more than one is non-zero.
* **Leaving the quaternion at all zeros** while expecting a rotation, or filling in both Euler and quaternion fields.
* **Forgetting that results are reported in the local frame**, and treating a correct reaction as an error because it does not match a global hand-check.
* **A wrong origin**, shifting a whole set of nodes while preserving their shape.
* **Restraining a skewed support in global axes anyway**, which is what the coordinate system exists to avoid, and which over-restrains the structure against thermal movement.


---

# 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/coordinate-systems-fea/coor-sys-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.
