Appendix

Verification record

What inWaves has been checked against, who owns each remaining difference, and where an error is systematic, which way it points.

Two things this record does that a ratio column cannot

A computed value, a reference value and a ratio tell you the size of a difference and nothing about its nature.

1. Every deviation has a declared owner

A distance from a target is not automatically our error. Some NAFEMS targets are the answer of a reduced theory (Mindlin plate, Timoshenko beam) while inWaves solves full 3D elasticity, and in a thick plate the 3D answer is the physically better one. Each label therefore carries an evidence obligation:

A label without its evidence is not permitted.

2. Known systematic errors state their direction

Where an approximation biases the answer consistently, the record says which way. From the limits document:

• Linear static analysis of a thin shell. A plate deflecting on the order of its own thickness stiffens geometrically through membrane stress. A linear solution has no such mechanism and reads the deflection systematically too high. The rule of thumb is roughly w > t/2, and the result does not announce it. Pressure loads do not rotate with the surface (they are not follower loads): the direction is the normal of the undeformed geometry.
• Temperature-independent material properties. E, ν, ρ and α_t do not vary with temperature; steel at 600 °C is read with its room-temperature modulus. In a hot run this is a systematic error: the real structure is softer, so the computation under-reads buckling.
• Linear tetrahedra in bending. On the FV52 8×8×3 mesh, P1 elements come out +67.00%. This is a universal element property, not a defect to be fixed. Use P2.

The head-to-head comparison, and why it is honest

Across the sixteen benchmarks with published competitor results, inWaves' mean absolute deviation from the targets is 1.44%, against ten commercial codes.

At the level of individual quantities, the tally across all compared rows is 38 ahead, 21 within the published band, 8 behind, 7 level. The eight losses are named in the record, with who beat us and by how much.

What "verification" means here, and how the record is built

The record holds 29 runs. Three source types are kept separate; they do not carry the same weight of proof:

• Standard benchmark. A vendor-independent problem with a published target value (the NAFEMS sets).
• Closed form. Comparison against an analytical solution.
• Literature / measurement. Correlation against published experimental data. This is validation rather than verification, and there is one such case: the GARTEUR SM-AG19 aircraft-like test structure.

Each run also declares its level. Scene means the benchmark was built and solved through the same commands the user interface calls. Core means the solver was verified at library level and the scene-level path does not exist yet; those rows are listed as feature gaps. Of the 29 runs, two are core-level only and one is part core, part scene.

Why the GARTEUR case is scored differently

Against a measurement, "within X% of the target" is the wrong test: the target itself carries uncertainty. It was measured at three levels. Repeatedly dismantling and reassembling the same structure in the same laboratory moved the elastic modes by a coefficient of variation of 0.02–0.42%. Measuring the same structure in twelve different laboratories gave typically ±2% on frequency. Building a second copy from the same drawings moved the modes by 1% to 16%. The dominant uncertainty is the copy, not the test. Without tuning a single parameter to the measurement, the run's mean absolute frequency error over ten matched modes is 3.71%; a published beam model of the same structure gives 6.13% untuned and 2.67% after updating 21 parameters against the measurement itself.

Representative results

A selection. "Worst error" is the largest deviation anywhere in that run, not an average. The complete per-mode tables and the head-to-head figures are in the repository's verification report.

Twenty-six of the twenty-nine runs; the remaining three are element-variant repeats of rows already shown (FV5/5H with beam elements, FV22 with shell elements, 21H with shell elements), each landing between 0.67% and 2.94%.

Reading the two worst rows

NAFEMS LE9, −18.87% while every published competitor lands between −1.5% and −4.9%. The owner is stated as the joint idealisation, not the element: the mesh sequence converges slowly and from above (244 → 2400 elements: −255.6 → −259.5 MPa), Aitken extrapolation puts the continuum limit at −259.7 MPa, so the discretisation share of the gap is 0.04 points and the remaining 18.83 points belong to the idealisation itself. All the competitors run axisymmetric shell elements, in which three mid-surfaces meet at a point and the branch transmits a moment. A continuum has no such point, and in the NAFEMS solid geometry the sphere wall lands on the inner face of the main wall. The measured through-wall profile shows exactly that asymmetry. No published competitor uses our idealisation on LE9, so there is nothing to compare against.

Shell obstacle course, −59.93% at its worst. That figure is the 4×4 mesh of the hemisphere with a hole, the coarsest level of a deliberate refinement ladder; the published competitor range on the same row spans −61.40% to +2.70%. By 8×8 the same quantity is at −0.31% and by 32×32 at +0.46%. Quoting the worst number without the ladder would misrepresent the row in the other direction.

Reproducing a result yourself

Every scene-level row was built through the same commands the interface issues.

1. Pick a row and read its declaration. Every entry states its solver, element type, boundary-condition realisation, source and level. For NAFEMS FV52 that is: modal solve, P2 tetrahedra or HEX bricks, direction-constrained (diaphragm) supports, target 45.897 Hz for mode 4.
2. Build it in the product. Create the plate with Create Box Part…, which is born with its mesh. Assign the material, place the supports with the same direction mask the record names, and run Solve Modes.
3. Compare like with like. On that benchmark inWaves reports 45.98 Hz against the 45.897 Hz target, +0.18%. If you get something else, the difference is almost always the boundary condition: the same plate solved with the softer realisation converges to 44.241 Hz, −3.61%. That is the idealization label.
4. Establish your own error band. Run Convergence Check… on your model. It solves on the current mesh and again one level finer and reports the discretisation uncertainty by Richardson extrapolation. Asking for three meshes measures the convergence order instead of assuming it. The fine mesh exists only in memory; your project is untouched.
5. Check the element choice. The FV52 entry records the same mesh solved with different element families, so you can confirm the +67.00% cost of P1 tetrahedra in bending on your own machine.

Three checks in the product apply to your own models: Convergence Check… for mesh dependence, Mesh Adequacy for whether the mesh can represent bending at all, and the free-free rigid-body modes as a constraint sanity check. See Troubleshooting.

What bounds the record

The limits are documented with the measured cost attached where one exists. Nonlinearity of every kind is out of scope (contact, plasticity, large displacement, damage), heat conduction is not solved so a temperature field is an input, and composite failure criteria are not evaluated. Each is a scope decision.

How this record is kept current

The comparison summary was produced on 7 August 2026 and the detailed report on 9 August 2026 at commit 03c3106; the manual as a whole describes inWaves 0.1.0. Every row is regenerated from a script in the repository rather than transcribed by hand. When a solver changes the numbers are re-measured, including in the unfavourable direction.

All figures are transcribed from the repository's benchmark records: benchmarks/DOGRULAMA.md (verification runs and deviation ownership), benchmarks/KARSILASTIRMA.md (head-to-head summary) and benchmarks/SINIRLAR.md (limits and measured costs). Competitor figures are from the respective vendors' published verification documentation; product names are trademarks of their owners. The record has not been independently audited.