> 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/verification-fea.md). # Verify \[FEA] A Verify object is an automated check embedded in the model. It evaluates a value — typically an analysis result — compares it against one or more reference values using a chosen operator, and reports pass or fail. Checks live in the project and re-run with it, so a model that once matched a benchmark keeps proving it matches after the model, the library, or the solver changes. Its purpose is regression protection and validation: reproducing a textbook problem, matching a benchmark from another package, or asserting that a design quantity stays within a limit. Verify objects are **reporting only**. They add no stiffness, mass or load, and they never influence the analysis they are checking. ## Verify **Value:** The quantity being checked. This is normally an expression that reads an analysis result, but it can be any expression the model can evaluate. *Engineering influence.* This defines what is being asserted; everything else on the object describes how the assertion is judged. An expression that fails to resolve — a renamed element, a case that did not run — yields no value, and the check cannot pass. Because the expression is evaluated against solved results, a Verify object in a project whose analysis has not been run reports nothing rather than failing. **Op:** The comparison operator: Equal, Greater Than, Greater Than or Equal, Less Than, Less Than or Equal, or Not Equal. Choose the operator that matches the intent of the check. **Equal** is the right choice for reproducing a benchmark, where the model should land on a known answer within tolerance. The inequality operators express design limits — "this displacement must stay below the serviceability cap" — and stay valid as the model improves, whereas an Equal check against a value that was never a true benchmark becomes a maintenance burden that fails every time the model legitimately changes. Equality on a floating-point result is only meaningful with a tolerance; the object carries absolute and relative tolerance settings for exactly this reason. A check that fails by a fraction of a percent is usually a tolerance that is too tight, not a broken model. **Analysis Case:** The case whose results the check reads. A check pointed at a case that is inactive or did not solve has nothing to read. **Element:** The element the result is taken from, where the check targets an element result. **Node:** The node the result is taken from, where the check targets a nodal result. **Force Effect:** Which force or displacement component is read — the specific column of the result table being asserted on. **Result Type:** The kind of result being read, which determines how the value is extracted and which of Element, Node and Force Effect are meaningful. *Engineering influence, for these five together.* They form the address of the result. They must be mutually consistent: a nodal displacement check needs a Node and a displacement Force Effect, while an element end-force check needs an Element and a force component. A mismatched combination — naming an Element but selecting a nodal result type — resolves to nothing, and the check reports no value rather than explaining the inconsistency. When a check produces no value, work through this address first. Object references here are by **name**. Renaming the element or node a check points at will break the check unless the rename is propagated. ## Ref **Verify Value:** The value actually produced by the check on the last run — the result side of the comparison, shown for inspection. Read-only in practice; it is output, not input. **Ref1 Name:** A label for the first reference value — where the number came from. Use it to record the source: the package and version, the textbook and example number, the hand calculation. A reference value with no provenance is very hard to re-justify later, and this field is the only place that provenance is kept. **Ref1 Value:** The first reference value the result is compared against. **Ref2 Name / Ref2 Value:** A second reference, with its own label. **Ref3 Name / Ref3 Value:** A third reference, with its own label. *Engineering influence.* The three slots exist so one quantity can be checked against several independent sources — for instance a commercial package, a closed-form solution, and a published benchmark. Where they disagree, the spread is itself informative: it tells you the achievable tolerance for that quantity, and a model landing inside the spread is arguably validated even if it does not match any single source exactly. Leave unused slots empty. A reference value of zero is treated as a real reference, not as "unset", so relative-tolerance comparison against zero should be avoided in favour of an absolute tolerance. ## Verification * Run the analysis and confirm the check reports a value at all. No value means the result address (case, element, node, force effect, result type) does not resolve. * Deliberately perturb the model — change a section, a load, a support — and confirm the check fails. A check that passes no matter what is not testing anything, and this is the only reliable way to find one. * Compare the reported Verify Value against the reference by hand the first time, before trusting the automated comparison. * Where several references are supplied, confirm they agree with each other to the precision you are asserting. * Re-run after any library or solver change and treat a newly failing check as a real finding until shown otherwise. ## Common mistakes * **A check that can never fail**, because the address does not resolve and no value is ever produced. This is the most damaging failure mode: it looks like a passing test suite while testing nothing. * **Equality checks with an unrealistically tight tolerance**, failing on ordinary floating-point and meshing differences and training everyone to ignore failures. * **Reference values with no Ref Name**, leaving nobody able to say where the number came from or whether it is still applicable. * **Checking a quantity that is not actually sensitive** to what the model is meant to prove — for example verifying a support reaction, which equilibrium fixes regardless of whether the element formulation is right. * **Renaming the referenced element or node** and silently breaking the address. * **Comparing against a reference from a package configured differently** — different units, a different shear-deformation assumption, a different mass source — and treating the mismatch as a defect in this model. --- # 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/verification-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.