Validation & method provenance

A pile-analysis tool is only as good as your trust in its numbers. New software earns that trust the way the profession has always demanded: by citing its method provenance and benchmarking against the codes engineers already rely on. Here is exactly how PileCalc is validated — and how you can check it yourself.

Method provenance

Every model in PileCalc traces to a named, published source — the same sources LPILE and RSPile cite. Nothing is a black box.

• Governing equation: the beam-column on a nonlinear (Winkler) foundation, from COM624P (Wang & Reese, 1993, FHWA-SA-91-048). See the p-y method.
• p-y curves: Matlock (1970); Reese, Cox & Koop (1974); Welch & Reese (1972); API / O'Neill & Murchison (1983); Reese (1997) weak rock.
• Axial & shafts: NAVFAC DM-7.02 static methods; t-z / q-w load transfer; FHWA-IF-99-025 (O'Neill & Reese, 1999); Vesić (1977) settlement.
• Footings: the general bearing-capacity equation with Meyerhof / Vesić shape, depth, and inclination factors.

The frozen benchmark manifest

On top of the engine's regression suites, every analysis type is registered in a machine-readable validation manifest: a named method and edition, its public sources, and a set of frozen benchmark cases — checksummed input/expected-output vectors drawn from exact solutions, FHWA/NAVFAC/USACE worked examples, and independently executed reference code. CI executes every case against the live engine on each release, so a stored expected value can never drift with the implementation. All cases currently pass.

Calculators marked shared engine call the same analysis functions validated by the capability table above — a spot check in any calculator must match the full tool exactly. The manifest is a living program — we keep adding cases (field load-test comparison sets, additional worked vectors) as public sources are transcribed and frozen. Every response the API returns is stamped with the method, edition, and engine version that produced it, so a saved analysis stays auditable against the registry that validated it.

Equation-level agreement

The RSPile Laterally Loaded Piles Theory Manual documents the governing equation and every p-y model. We checked the PileCalc formulation against it term by term — the Matlock pu expression, the y₅₀ = 2.5·ε₅₀·b relationship, the Reese sand wedge with its tan⁸ term, the API tanh form, the Reese–Nyman weak-rock reduction. The equation forms are identical. RSPile uses finite elements and PileCalc uses finite differences, but that is a discretization choice; the governing physics is the same.

Numerical benchmarks, by tool

Every tool in PileCalc — all sixteen, including the newest (capacity vs length, torsion, downdrag, foundation stiffness, buckling, helical piles and the pile cap) — is anchored to published cases with a known answer: a closed-form solution, a design-manual table, or an independent code (LPILE / RSPile). Most tools carry one to three citable cases; the lateral p-y solver and the section engine go further, reproducing some thirty worked examples against the printed output tables of an independent commercial p-y code — the strongest of those appear below. We run the engine on the exact same problem and compare. Every figure below is reproduced by the test suite, so the numbers in this table are generated, not transcribed.

How to read the table

The reference column draws on three kinds of evidence, strongest first:

• Closed-form / exact — an analytical solution with no discretization (Hetényi's beam on an elastic foundation; plastic section moduli; the bearing-capacity factor formulas). Agreement here is a pure test of the solver, and it lands within a fraction of a percent.
• Published design tables — values every engineer already uses: the NAVFAC Nq factors, the Vesić Nc/Nq/Nγ table, the FHWA β-method bounds, the p-multiplier deduction factors. PileCalc reproduces them to the printed precision.
• Independent codes & textbook examples — LPILE, RSPile, and worked examples from Das. A few of these carry a chart-reading tolerance or a documented method convention (see the footing q_ult case, where a depth-factor convention accounts for the 2% offset).

Two codes, not one

We deliberately benchmark against both LPILE and RSPile. They are independent implementations — different teams, different numerical methods, even opposite sign conventions for moment and soil reaction. If PileCalc matched only one, you could not rule out that it had inherited that program's idiosyncrasies. Matching both, plus closed-form solutions and primary-source worked examples, is much stronger evidence that the solver is right. (It is also why sign conventions differ between tools — compare magnitudes and locations, not raw signs.)

What validation does & doesn't mean

Validation means the math is faithful to the published methods and reproduces accepted benchmarks. It does not remove engineering judgment. The p-y method itself has limits, soil parameters carry real uncertainty, and you remain responsible for reviewing results for design. PileCalc's job is to make every assumption and intermediate value visible so that review is actually possible — and then to get out of your way.