Theory Series, Part 5: Numerical Consistency
Numerical Consistency Check (Planar Model)
Plain-Language Summary
This article sets up tests to check that our computer code solves the swing equations correctly. Code tests make sure the math is right, but they do not prove how a real person swings.
Key Takeaways
- Numerical verification evaluates whether code correctly integrates declared governing equations.
- Empirical validation requires independent measurement, identified physiological parameters, and uncertainty bounds.
- Simulated planar trajectories cannot be promoted to human predictive validity without empirical calibration.
These entries remain visible until evidence-backed adjudication changes their governed status.
- Open / High: Critique: The Flaccid Drift Contradiction (
crit-flaccid-drift-contradiction) - Open / Medium: Critique: The Simulation Tautology (Circular Validation) (
crit-simulation-tautology) - Open / High: Critique: The Validation Dimensionality Gap (
crit-validation-dimensionality-gap)
What This Numerical Procedure Establishes
A simulator can check whether an implementation solves its declared equations consistently. That is numerical verification. Whether those equations predict a golfer’s motion and loads is an empirical validation question requiring separate measurements, identified parameters and uncertainty.
The proposed branch experiment sets the declared torque channel to zero while retaining the specified state and plant. It preserves momentum, elastic deformation and any declared auxiliary states. It does not establish that a golfer could reproduce the intervention, or that continued motion measures a passive share of performance.
A planar model can test force balance, modal coupling, energy accounting and solver convergence in its own degrees of freedom. It cannot establish spatial gyroscopic behavior involving the full angular-velocity cross product, bilateral grip-force allocation, or three-dimensional contact accuracy. The particular planar coordinates, constraints and shaft approximation must be specified; the word “planar” alone does not determine the number of degrees of freedom.
The checks below are a reproducibility protocol. They do not report a newly executed full-golfer Simulink study or establish novelty of the method. The worked pendulum supplies independently checkable mathematical examples; the counterfactual discussion supplies branch, uncertainty and event conventions.
Simulink Forward Dynamics Modeling and Counterfactual Evaluation
Reproducible Evaluation Procedure
Use the same model, parameter set, generalized-coordinate convention and external loads for each paired evaluation. Record whether constraints are eliminated or enforced, and what the force output actually measures.
- At each measured or simulated state, compute \(M\), \(h\), and the applied generalized load \(\tau_{\mathrm{ID}}=M\dot v+h\).
- Solve \(M a_d=-h\). Verify \(M a_d+h=0\) and \(M(\dot v-a_d)=\tau_{\mathrm{ID}}\) within declared tolerances.
- Evaluate \(h_0=h(z,0)\) at the declared velocity-reset state. Report the signed configuration drift \(-h_0\) or holding load \(h_0\), with its convention. Do not use inverse dynamics on \(a_{\mathrm{ZVCF}}\) to obtain \(h_0\).
- For reaction forces, solve the constraint/reaction equations twice at the same state, once with the declared input and once without it. Compare homologous outputs in the same frame and at the same reference point.
- For a forward ZTCF, initialize once at \(x(t_0)\) and integrate \(\dot x=f(x)\) using the evolving counterfactual state. For branched ZTCFs, restart at each selected actual state and keep the branches separate. Reinitializing at every actual sample produces pointwise samples or short branches, not one forward trajectory.
Conceptually, the force bookkeeping is:
for each actual sample (z, v, acceleration):
M = inertia(z)
h = bias_load(z, v)
drift_acceleration = solve(M, -h)
applied_load = M @ acceleration + h
resultant_load = M @ acceleration
drift_load = -h
configuration_drift = -bias_load(z, zero_velocity)
velocity_drift = drift_load - configuration_drift
check(resultant_load == drift_load + applied_load)
forward_ztcf = integrate(drift_field, initial_state, declared_horizon)The equality is an implementation check for the declared equations, not an independent validation of human biomechanics. A nonzero inverse-dynamics residual in a nominally zero-input run can expose unmatched external loads, incorrect state ordering, inconsistent constraint treatment, or numerical error.
Verification and Empirical Limits
Publish model/source revision, initial states, input histories, contact rules, force definitions, units, solver tolerances, convergence studies and raw result artifacts before treating a numerical observation as reproducible evidence. Check analytic limits, energy balance, forward/inverse consistency, sensitivity to modal truncation and parameter uncertainty, and event/reset handling. Identical solvers are neither necessary nor sufficient: independent converged implementations provide a stronger cross-check than matching solver names.
A stiff shaft model may need an implicit integrator. Large path curvature alone does not establish numerical stiffness. Select a method using the model’s time scales and measured convergence (Hairer and Wanner 1996). Kinematic differentiation and filtering uncertainties also need propagation into estimated loads; filtering cannot establish an unmeasured bilateral force allocation.
The historical Simulink narrative on this site is a description of intended or reported computations. This page does not supply a revision-bound run package for the reported 56 interventions, so their numerical and hand-specific outcomes are not treated here as verified results. Such a package would establish model verification; external measurements and identified parameters would still be needed for human validation.
Worked Example: Integrating the Forward ZTCF Trajectory
Given: the same golf configuration as the Part 2 pointwise example — SEGMENTS at \(q=(60^\circ,-30^\circ,-20^\circ)\), \(\dot q=(12,-18,-25)\) rad/s — integrated forward under zero applied torque for \(0.10\) s in \(400\) steps (step 5 of the procedure above).
Steps:
- Call
SEGMENTS.ztcf_trajectory(q0, qd0, duration=0.10, steps=400). - Read the reported clubhead speed at the first and last sample.
Result: clubhead speed falls from \(35.37\) m/s at \(t=0\) to \(21.66\) m/s at \(t=0.10\) s — a \(-38.8\%\) change along this one declared zero-torque branch. This is the integrated counterpart of the instantaneous drift evaluated in Part 2; it is a property of this one model and branch, not a measurement of a golfer’s passive contribution.
Computed by src/affine_control/golf_model.py::GolfModel.ztcf_trajectory; checked against this page by tests/test_worked_example_callouts.py::test_theory_part5_forward_ztcf_trajectory.
Revision History
2026-09-08: Standardized cross-article category metadata and link targets (#4302).
2026-09-05: Explicit numerical verification boundaries for planar model (#4195, #4153).
2026-08-29: Governed claim and critique adjudication framework (#4051).
2026-03-10: Three-pass professional assessment and formalization.
References
Citation
@online{olson,
author = {Olson, Dieter},
title = {Theory {Series,} {Part} 5: {Numerical} {Consistency}},
date = {},
url = {https://affinedrift.com/articles/theory-part5.html},
langid = {en},
abstract = {This article defines a numerical verification protocol for
control-affine planar swing simulations. It provides an explicit
distinction between verifying that computational routines faithfully
solve their governing equations and empirically validating those
models against human subject biomechanics.}
}