Validating a model

Every BriskFyr tutorial ends the same way: not "it moved," but a number, checked against a hand-worked closed-form result.

• Tutorial 1 — a falling body drops exactly s = ½gt².
• Tutorial 2 — a pendulum's period matches T = 2π√(L/g).
• Tutorial 4 — a spring–mass system's natural frequency matches ωₙ = √(k/m), and its damping ratio matches ζ = c/(2√(km)).
• Tutorial 5 — a pushed body's acceleration matches a = F/m (or α = τ/I for a torque).
• Tutorial 6 — a rigid link's length stays constant to the solver's tolerance, read as an exact number via a Distance Request.

The pattern generalizes to any model you build: pick a quantity the physics predicts on paper — a period, a frequency, a reaction force, a final velocity — set up a Marker and Request to read the equivalent number out of the solve, and compare. If they don't agree within a small tolerance, something about the model (not the physics) is usually the cause — a joint pinned to the wrong axis, an offset that's smaller than intended, a unit typed in the wrong convention.

This habit — validate the small, obviously-correct case before trusting a complex one — is why the tutorials build up gradually (one node → one joint → one load) rather than starting from a full mechanism.

Work through the full tutorial set