Appearance
Verification & validation
How do you know the numbers are right? CivilKit Studio is built to be checked, not trusted blindly - here is what is tested, how you can see it yourself, and what is still maturing.
Why this matters
"Verification" asks did we solve the equations correctly - does the maths match known answers. "Validation" asks are we solving the right equations - does it match the engineering standards and real catalogues. CivilKit Studio takes both seriously and, just as importantly, is honest about where the work is not finished. None of this replaces your own judgement - see the warning at the end.
About & validation
Open Help → About & validation (the menu item with the tick) for a one-screen snapshot of how the engine is checked. Everything runs locally in your browser on a WebAssembly solver - nothing is sent to a server. The summary it gives, and the live record behind it, cover:
- Analytical benchmarks - 40 closed-form cases (cantilevers, simply-supported and continuous beams, propped and overhanging beams, fixed-fixed, an L-frame bent, 2D/3D trusses, torsion, simply-supported and clamped plates, Euler buckling under four end conditions, natural frequencies, second-order P-Delta and member end releases) where the answer can be worked out by hand. The solver matches the closed-form answer within each case's own tolerance - about one part in ten thousand for the beam and truss cases.
- Independent solvers - displacements and reactions on random 3D frames agree with an independent open-source structural solver (PyNite) to the last printed digit, and the nonlinear and plate paths are cross-checked against OpenSees and CalculiX on an identical mesh.
- Reference oracle - a separate, independently written solver (in numpy) used as a second opinion across all six degrees of freedom.
- Physics invariants - the model is forced to obey physics: everything that goes in must come back out as reactions (equilibrium), plus reciprocity and load superposition - all asserted automatically.
- Section data - the country section catalogue (AU / US / EU / UK / CA / TH), with mass and stiffness cross-checked against the stated dimensions.
- Design codes - the dialog lists the standards in play: AS 4100 steel (members and connections), AS 4600 cold-formed, AS 3600 concrete, AS 2327 composite, AS 1720.1 timber, and AS/NZS 1170.0 load combinations.
Plain-language takeaway
On the core analysis - how the structure bends, deflects and carries load - the engine reproduces hand calculations and an independent solver to many decimal places. That part is on solid ground.
Nonlinear analysis
Large-displacement and plastic analysis is checked the same way as the linear solver: against hand calculations where one exists, and against OpenSees - a different program, written by different people - on an identical mesh where one does not.
| What was analysed | Compared against | Difference |
|---|---|---|
| A cantilever curled into a circular arc by an end moment | the exact elastica - the arc's radius is EI/M, whatever mesh you use | 0.02% |
| A cantilever under a large tip load (deflecting more than half its length) | Mattiasson's published elliptic-integral table | matches the table |
| The 45-degree bend: a curved cantilever pushed sideways out of its own plane | OpenSees, same 8-element mesh | 0.06% |
| A steel cantilever loaded past yield, with the section modelled fibre by fibre | OpenSees's force-based fibre element | 1.05% |
| A rigid base plate on concrete that cannot pull, loaded off-centre so one edge lifts | the textbook result: bearing over 3(L/2 - e), peak pressure 2N/(ba) | 0.4% on peak pressure, and the same lift-off point across a hundredfold change in the concrete's stiffness |
| An X-braced bay whose braces can only pull | a hand calculation, and OpenSees | 0.05% against the hand calculation; identical to six decimal places against OpenSees |
| A catenary cable hung under its own weight, shallow and deep, then point-loaded at mid-span | Irvine's closed-form catenary, and OpenSees's CatenaryCable element on the same cable | 4e-6 against Irvine; 7e-11 on the sag and 3e-8 on the horizontal tension against OpenSees |
| A haunched portal frame's factored gravity combination (1.25 G + 1.5 Q), solved second-order | Microstran's published second-order run of the same frame (Woolcock, Design of Portal Frame Buildings, Appendix II) | vertical reactions to the printed kN; thrust and every member end moment within 0.5 %; axials within 1 % |
The plate row is worth a word. That textbook formula contains no soil or concrete stiffness at all - lift-off happens where it happens regardless. So the check is not just "does our number look right", it is "does our number stay put when we change something the answer must not depend on". It does.
What this does not yet cover
Analysis of this kind is newer than the linear solver, and some of it is deliberately refused rather than approximated:
- Bearing surfaces are not yet part of a frame model. The element that lets a base plate lift off exists and is checked, but you cannot yet draw one; base plates and anchors use their own separate calculation.
- Twisting stays elastic in the plastic analysis, and the program says so on every result rather than leaving you to assume otherwise.
- Snap-through and collapse tracing (arc-length) is available for flat frames only. On a three-dimensional model it is refused by name, because an unverified collapse load is worse than none.
- A cable is a catenary only when you say so. The chord model (the default) goes slack correctly but carries no self-weight sag; choose catenary in the member inspector for a cable that hangs. Cable-to-cable contact is not modelled.
The full record, with every reference value and the test behind it, is in docs/reference/nonlinear_validation.md in the source tree.
The in-browser verify suite
You do not have to take the About box on faith. Open Help → Verify suite (or press V) to launch verify.html, a page that re-runs the benchmarks live in your own browser, right now, and shows a pass/fail table.
Each row is a structural case that is solved by the same WASM solver you use for real work, then compared against its hand-derived closed-form answer. The page reports, per case, how many quantities were checked and the worst-case error, with a per-case tolerance (0.01% for exact beam theory, looser for the plate cases to absorb mesh discretisation). The header tallies the totals, for example "40 / 40 passed - worst-case 1.0e-4%", and stamps the run with the date and time.
That date stamp is deliberate: a screenshot of verify.html is a self-contained, dated quality record you can keep in a project file or hand to a reviewer.
This is yours to run any time
If you ever doubt a result, run the verify suite. A green page means the solver on your machine is reproducing known-good answers to within a thousandth of a percent.
Catalogue & code caveats
Confidence on the solver does not extend evenly to every feature. The honest gaps:
- Section catalogues are not yet engineer-verified. The country section libraries are marked
verified: false- the dimensions and properties are indicative for early-stage work and still awaiting a cross-check by an engineer against the manufacturer's published tables. Always confirm a section's data against the catalogue before relying on it. - Connections are still maturing. The connection designer covers the common steel joints, but it is not yet hardened - treat its output as a first-pass check, verify the detailing, and confirm against the standard.
- Timber is cross-checked, not verified. Timber design to AS 1720.1 reproduces an independent implementation over 1,100 cases and the SA HB 108 worked examples, but it has not yet been checked against the standard's own pages. Combined actions and timber connections are not designed.
- Plates are analysis-only. Plate/shell elements give displacements and stresses but coarse-mesh accuracy is still under mesh-convergence validation - there is no plate design check yet.
- International wind: the US path carries surfaces, the UK/EU path is site pressure only. For a US project the wind wizard runs ASCE 7-22 and gives the velocity pressure with every factor behind it, the Fig. 27.3-1 wall and roof coefficients,
p = q G C_pwithG = 0.85for a rigid building, and the Table 26.13-1 internal pressure on both signs - so a US project does get per-surface pressures to paint on the model and put in the report. Not carried for ASCE: a flexible-buildingG_f, Chapter 30 components and cladding, the Chapter 28 envelope, andK_ztis typed in. EN 1991-1-4 carries the peak velocity pressure only - no pressure coefficient at all - so a UK/EU project has no surface pressures on that path, and the dialog says so beside the number. Australian and New Zealand projects get the full AS/NZS 1170.2 treatment including per-surface pressures, which is unchanged. - New Zealand steel runs NZS 3404, and two clauses of it are not carried. Sections 5, 6, 7, 8, 9 and 12 are implemented from the printed standard and a New Zealand project is checked to them by default - members, connections and auto-sizing alike. Two things are deliberately NOT claimed: Cl 5.13 web bearing, because AS 4100's implementation reads the AS 4100 clause and the documents are not identical; and angles, whose leg is a single outstand of its full width, so they are named in the unchecked-members list rather than checked under an I-section layout. A member that needs either still needs it. You can still pick AS 4100 on the Design panel to compare the two, and every surface that names a code says which one produced the number.
- AS 4100 angles are checked in one arrangement only. A single angle that is a pin-ended (truss) member - a brace or truss web bolted or welded through one leg - is checked to AS 4100 Cl 8.4.6, with the eccentricity of that connection. The tension check is gross yield; check the net section with your real holes (the kt used is shown). An angle used as a frame (beam) member, and two angles back to back, are named in the unchecked-members list: the model does not carry an angle's orientation, and a double angle needs its interconnector spacing.
- Design checks use simplifying assumptions. Member design checks default effective lengths to the member length with no intermediate restraints, and use conservative defaults you should review per member.
The internal V&V test suite
Behind the two things you can click, the project also ships an automated correctness suite that the developers run (npm run test:vv). At a high level it goes beyond the visible benchmarks: a finite-element patch test, mesh-refinement convergence, rigid-body checks, self-weight equilibrium, save/reopen result invariance, plus catalogue-integrity and end-to-end design checks. It exists so regressions are caught before they ever reach you - you do not need to run it, but it is part of why the numbers hold up release to release.
The result is still your responsibility
Verification tells you the tool computes what it claims to compute. It does not confirm that your model, restraints, load cases, section data or governing combination are correct for your structure. Always cross-check section data against the manufacturer's catalogue, confirm restraints and effective lengths, and verify any design result against the relevant standard before relying on it for professional use.