Computational Engineering
Model assurance
The checking workflow gathered into one page: what to state before building, what to look at, what to compute by hand, and what to write down.
A solver checks that the model it was given is solvable. It cannot check that the model is the one you meant to build, and every silent failure in this course has that shape: a correct analysis of the wrong structure, in equilibrium, with no warnings.
Everything below is a check the model cannot perform on itself. None of it takes long, which matters more than it sounds — a check that takes half a day does not get done under programme pressure, so it does not matter how good it is.
The workflow
01 State what the model is for
Module 6One sentence naming the question, and one naming what would make the model wrong. Without the first there is no subject; without the second there is nothing falsifiable, and a model nothing could disprove is not being used to find anything out.
02 Predict the answer before building
Module 21Written down, before the model runs. A prediction made afterwards is not a prediction — it becomes a search for reasons the number might be right.
03 Look at it and think
Module 13The deflected shape, the reactions, the sign of everything. Most defects are visible here and cost nothing to find. A discontinuity in a deflected shape is a disconnection; a zero where a reaction should be is a missing restraint.
04 Check the arithmetic the model cannot check
Module 13Total applied load against total reaction. The equilibrium residual, read rather than assumed. One member by hand at the clear span. These take minutes and are the only checks that catch a model that is internally consistent and wrong.
05 Check it another way
Module 8A different method on the same structure — a hand calculation, a coarser model, a published solution. The per-system table below is the shortlist.
06 Record it so somebody else can repeat it
Module 5Model version, software version, inputs and where each came from, the assumptions that were choices rather than data, and the checks that were run with what they gave. A model that is right but unidentifiable is not usable.
One hand check per system
Step 5, made specific. Each row is the usual model, the thing it gets wrong often enough to check every time, and a calculation that needs no software.
| System | Usual model | Watch for | Hand check |
|---|---|---|---|
| Truss | Pin-jointed bar model. | Chord continuity puts bending into members sized for axial force alone; and the panel loads are not a UDL. | Chord force ≈ M/d at midspan, with M from the actual point loads rather than a smeared equivalent. |
| Steel frame | Line elements, connections either rigid or pinned. | Real connections are neither. The sway and the eaves moment both depend on a stiffness rarely calculated. | Portal method or a sub-frame by moment distribution: it will land within a few per cent of a correct model. |
| Composite floor | Beam elements with a transformed section. | The effective width assumed, and whether the model quietly uses the composite stiffness for the construction stage too. | wL²/8 on the bare steel for the construction case, and again on the composite section for the in-service case. |
| Flat slab | Shell mesh with column supports. | The peak moment over a point support is a singularity and grows without limit as the mesh refines. | Total static moment across a panel width must equal wL²/8 — integrate the model's moments and compare. |
| Core and shear walls | One stick element per core with the gross second moment of area. | Shear deformation is omitted by default and openings are usually not modelled at all. | Cantilever deflection wH⁴/8EI plus wH²/2GA — if the two terms are comparable, the stick model is not enough. |
| Foundations | Springs under the base, or full fixity. | Full fixity is almost never right, and a spring value taken from a default is a number nobody derived. | Compare the base moment for fixed and pinned. If the design changes between them, the soil stiffness is a governing assumption and needs a source. |
| Timber | Frame elements with the timber's modulus. | Connection slip dominates the deflection of a timber structure and no element captures it by default. | Add the slip of each connection along the load path by hand and compare with the model's total deflection. |
| Masonry | Shell elements, or struts and ties. | Tension. A linear elastic model will happily report masonry carrying tension it cannot carry. | Check the resultant stays within the middle third; if the model shows tension, the model is not describing masonry. |
| Floor vibration | The static model, reused, with masses added. | The static model's mesh and the static model's stiffness assumptions are both wrong for dynamics. | f₁ ≈ 18/√δ with δ the static deflection under the vibrating mass, in mm — a check that takes seconds. |
Model purpose statement
Step 1. Five fields, reported in the order they matter in.
Try it
Model purpose statement
Five fields. Fill them in and see what a reviewer could and could not do with what you have written.
One sentence. Without it the model has no subject.
The assumption that, if it turned out otherwise, would overturn the result.
Named before the result exists, so it is not chosen to agree.
Comma-separated. Writing an omission down converts it into a decision.
Keeps the model proportionate to the consequence.
- Fields present
- 0 of 5
- Reviewable?
- no
- Next gap to close
- question
Not reviewable, and not yet a model of anything: no question has been stated, so any result it produces answers something nobody wrote down.
Still missing, in the order they matter
- The question this model exists to answer
- What would make this model wrong
- How the result will be checked
- What is deliberately excluded
- What it will be used to decide
What this shows: The gaps are reported in the order they matter: without a question there is no subject, and without an invalidation clause there is nothing to review.
The three-stage check
Steps 3 to 5, in order: look and think, check another way, check independently.
Try it
Three-stage model check
Record what each check actually was. The workspace will not accept a stage marked done with no method recorded.
- Stages recorded
- 0 of 3
- Recorded without a method
- 0
Checking effort should be proportionate. A scheme-stage sizing needs Stage 1 and a quick Stage 2. A transfer structure carrying six storeys needs all three — and deciding which is itself part of the assurance.
Stage 1 — look and think
Minutes. Finds most faults.What did you look at? Displaced shape, moment distribution, discontinuities, symmetry, equilibrium.
Stage 2 — check it another way
An hour or two.What different route did you use? A hand calculation, a cruder model, a limiting case, an energy check.
Stage 3 — check independently
Days. Reserve it for what warrants it.Who or what was independent? A different person, a different model built from the brief, a different tool.
What makes each stage count
- Stage 1 must be predicted first. Looking at the result and then judging it is rationalisation, not checking.
- Stage 2 must be a DIFFERENT route. A finite element model checked by another finite element model from the same assumptions has been checked against nothing.
- Stage 3's independence is mostly about the person. A second engineer building from the brief makes different assumptions, and the disagreements are the assumptions nobody had made explicit.
What this shows: 'Checked' is not a record of anything. A check that cannot be named cannot be reviewed, and a reviewer cannot disagree with it.
Assurance workspace
Step 6. An assumption not written down cannot be reviewed.
Try it
Model assurance workspace
Build a model record. The workspace names what is missing rather than reporting a completeness score, because the fields are not equally load-bearing.
- Fields completed
- 0 of 14
- Load-bearing fields missing
- 6
- Record status
- incomplete
Missing, and why each matters
- Engineering question: What this model exists to answer, in one sentence.
- Analysis type, and why: The 'why' is a validation statement.
- Supports and releases: 'Bases pinned' needs a reason.
- Verification carried out: What check, against what, with what result.
- Deliberate exclusions: What was considered and left out, and why. A reviewer needs this to disagree.
- Limitations: What this model must NOT be used for. Write it for someone reading it out of context.
This produces a Queensferry model review record. It is a teaching artefact and a reasonable structure for organising the information. It is not a category 2 or category 3 checking form and makes no claim to satisfy any external requirement.
What this model exists to answer, in one sentence.
Name and date.
Name and date.
Results change between versions.
The 'why' is a validation statement.
Stated once, explicitly.
With the reasoning for anything not obvious.
'Bases pinned' needs a reason.
Including which were NOT run, and why.
What was reported and what was decided about each.
What check, against what, with what result.
Which variables, what range, what the answer did.
What was considered and left out, and why. A reviewer needs this to disagree.
What this model must NOT be used for. Write it for someone reading it out of context.
6 load-bearing fields still empty. A completeness percentage would be misleading here — these are the ones a reviewer needs most.
What this shows: An assumption not written down cannot be reviewed — and the exclusions matter as much as the inclusions, because they are what a reviewer can disagree with.
System validation workshop
The table above, made interactive: pick a system and commit to what its usual model gets wrong before revealing it.
Try it
System validation workshop
Pick a system. Decide what its usual model gets wrong before revealing it, then read the hand check that would catch it.
System
For the frequency check in the last row of the guide.
- Usual model
- Pin-jointed bar model.
What does this model get wrong often enough to check every time?
The frequency check, live
- Static deflection
- 10 mm
- Estimated f₁ = 18/√δ
- 5.69 Hz
Above the range where walking excitation is worst, so a dynamic model is a choice rather than a default. That judgement took seconds.
What this shows: A check that takes half a day does not get done. Every one of these takes minutes.
When a model is already wrong
The Model Doctor holds 80 cases across twelve categories of defect, each worked through the same seven steps — symptoms, the discriminating check, the diagnosis, the confirmation, the correction, the verification, and what generalises.
Where this is taught
Module 5 — Digital engineering workflows
How information moves between models — and why the losses that stop you are the safe ones.
Module 6 — From physical structure to analytical model
Abstraction as an engineering decision — what each level keeps, what it throws away, and what it may then be asked.
Module 8 — Modelling structural systems
Trusses, frames, floors and cores — the usual model for each, its usual failure, and the hand check that catches it.
Module 12 — Diagnosing computational models
The largest module in the course: what goes wrong, how each fault announces itself, and the discriminating check that separates it from the others.
Module 13 — Validation, verification and model assurance
Two different questions that get the same word. Predicting before analysing, the three-stage check, and a record somebody else can review.
Module 21 — The computational engineer in practice
Sixteen steps from a brief to a recommendation, carried through on a real project — and the judgement that no step covers.