CivilKit Studio

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 dialog shows:

  • Analytical benchmarks - 25 textbook cases (cantilevers, simply-supported and continuous beams, propped and overhanging beams, fixed-fixed, an L-frame bent, 2D/3D trusses, torsion) where the answer can be worked out by hand. The solver matches the closed-form answer to about one part in ten thousand.
  • PyNite parity - displacements and reactions on random 3D frames agree with an independent open-source structural solver to 0.0000%.
  • 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 - 425 sections across 6 country codes, 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.

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 tolerance of 0.1%. The header tallies the totals, for example "25 / 25 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 a first-pass slice. Timber design to AS 1720.1 is an early, honest feature: the timber catalogue is not yet engineer-verified, stability handling is simplified, 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.
  • 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.