2. THOR Head Resultant Acceleration Computation

Why the Resultant Must Be Built From Three Channels

A THOR head instrumentation package does not deliver a single "head acceleration" number. It delivers three orthogonal linear acceleration channels — typically labelled Head_X, Head_Y, Head_Z — measured by accelerometers mounted in the head assembly near the head CG. Injury criteria such as HIC are defined on the resultant translational acceleration at the head CG, so the first computational step in any THOR diagnostics workflow is to combine the three channels into a single time-aligned resultant trace:

a_res(t) = sqrt( a_x(t)² + a_y(t)² + a_z(t)² )

Two things routinely go wrong at this step and both corrupt every downstream metric. First, sign conventions: the resultant is sign-invariant, but the individual channels are not, and a channel that has been inverted relative to the dummy specification will still produce a plausible-looking resultant while masking a real polarity error in the raw data review. Second, units: THOR head channels are commonly reported in g while some data acquisition exports are in m/s²; mixing them silently scales the resultant by 9.80665 and inflates HIC by roughly two orders of magnitude. The computation itself is trivial; the engineering work is in verifying the inputs before and after the square root.

Establishing the Reference Convention Before Computing

Before any arithmetic, fix the coordinate system and sign convention explicitly and keep them consistent through the calculation, the plots, and the reported result. For a THOR head, the SAE J211 / ISO 6487 convention is the usual reference: +X forward (anterior), +Y to the dummy's left, +Z upward, with accelerations positive in the direction of the respective positive axis. A forward impact therefore produces a negative X acceleration pulse in the head-fixed frame if the accelerometer is oriented to measure reaction acceleration, or positive if oriented to measure inertial acceleration — the instrumentation specification for the specific dummy build is the authority here, not convention alone.

Practical verification steps that catch most errors before the resultant is computed:

• Confirm the channel units in the export header or the DAQ configuration; convert everything to g (or everything to m/s²) before combining.
• Check the static pre-impact baseline of each channel: with the dummy at rest, all three should sit near 0 g (or near +1 g on the vertical channel if the accelerometer is not gravity-compensated — resolve this explicitly).
• Confirm time alignment: all three channels must share the same sample rate and the same trigger time. A one-sample skew between channels is small but should be documented.
• Verify polarity against a known event — for example, a forward sled pulse should produce the expected sign on Head_X given the documented mounting orientation.

Worked Computation With Example Data

The following example uses synthetic sample values chosen to illustrate the arithmetic and the unit check; they are not measured test data. Suppose the DAQ exports three channels at 10 kHz in g, and at the peak of the impact pulse the samples are:

Compute the resultant at that sample:

a_res = sqrt( (-62.4)^2 + (8.1)^2 + (14.7)^2 )
      = sqrt( 3893.76 + 65.61 + 216.09 )
      = sqrt( 4175.46 )
      ≈ 64.62 g

Note that the resultant (64.62 g) is only slightly larger than the dominant X magnitude (62.4 g) because the lateral and vertical contributions are small — this is the expected behaviour for a predominantly axial pulse and is a useful sanity check. If the resultant came out dramatically larger than the largest single channel, suspect a unit mismatch on one channel (for example, one channel in m/s² while the others are in g).

If the same Head_X sample had been exported in m/s² as −612.0, the naive resultant would be sqrt(612.0² + 8.1² + 14.7²) ≈ 612.3 — a value that is dimensionally meaningless and would inflate HIC by roughly a factor of 100. Converting first (−612.0 / 9.80665 ≈ −62.4 g) restores the correct 64.62 g.

Vectorised Implementation and Verification

The computation is naturally vectorised over the full trace. The following Python snippet is self-contained: it defines the example channels, performs the unit check, computes the resultant, and reports the peak with a verification assertion.

import numpy as np

G = 9.80665  # m/s^2 per g

# Example synthetic channels (g), 10 kHz, 50 ms window
fs = 10_000
t = np.arange(0, 0.050, 1/fs)
ax = -62.4 * np.exp(-((t - 0.020) / 0.004)**2)   # dominant axial pulse
ay =   8.1 * np.exp(-((t - 0.020) / 0.004)**2)
az =  14.7 * np.exp(-((t - 0.020) / 0.004)**2)

# Unit check: all channels must share the same unit before combining
units = {"Head_X": "g", "Head_Y": "g", "Head_Z": "g"}
assert len(set(units.values())) == 1, f"Mixed units: {units}"

# Resultant in g
a_res = np.sqrt(ax**2 + ay**2 + az**2)

peak_idx = int(np.argmax(a_res))
peak_g = a_res[peak_idx]
peak_ms2 = peak_g * G

print(f"Peak resultant: {peak_g:.2f} g  ({peak_ms2:.1f} m/s^2) at t={t[peak_idx]*1000:.1f} ms")

# Verification: resultant must be >= the largest single-channel magnitude
assert peak_g >= max(np.max(np.abs(ax)), np.max(np.abs(ay)), np.max(np.abs(az))) - 1e-9
# Verification: resultant must be <= sqrt(3) * largest channel (triangle inequality bound)
assert peak_g <= np.sqrt(3) * max(np.max(np.abs(ax)), np.max(np.abs(ay)), np.max(np.abs(az))) + 1e-9
print("Verification passed.")

Expected output for this synthetic input: Peak resultant: 64.62 g (633.7 m/s^2) at t=20.0 ms, followed by Verification passed. The two assertions encode the geometric bounds that any correct resultant must satisfy: it can never be smaller than the largest single channel, and never larger than √3 times that channel. A failure of either bound almost always indicates a unit or sign-handling error upstream.

Reading the Resultant Against the Instrumentation Specification

Once the resultant trace is computed, cross-check it against the THOR head instrumentation specification before handing it to any injury criterion. The specification defines the channel names, the mounting orientation, the nominal sensitivity, the measurement range, and the units. Three checks close the loop:

1. Range check: the peak resultant must lie within the specified measurement range of the head accelerometers. A peak that exceeds the range indicates either a real high-severity event or a scaling error; the specification tells you which is plausible.
2. Unit check: the reported peak must be in the unit the specification uses for the injury criterion (typically g for HIC). Report both g and m/s² in the diagnostics log to make the conversion auditable.
3. Sign check: although the resultant is sign-invariant, the individual channels must match the documented orientation. Record the sign of each channel at the peak so a reviewer can confirm the mounting orientation was respected.

Common Failure Symptoms and Troubleshooting

The resultant trace produced here is the input to the next stage of THOR head diagnostics — HIC computation and filtering sensitivity — but that work depends on this step being correct in units, sign convention, and time alignment. Verify the three channels against the instrumentation specification first; the square root is the easy part.