4. Data formats and interoperability

Crash-safety analytics rarely lives inside a single solver. A restraint system may be developed in MADYMO, the full vehicle body may be solved in LS-DYNA, and a legacy occupant model may still be maintained in PAM-CRASH. The moment you try to correlate belt forces, head acceleration, or intrusion across these tools, you are no longer doing simulation — you are doing data integration. This chapter explains the four file families you will meet most often, what each one actually stores, and where conversions break.

The four format families and what they carry

It helps to separate model definition from result data, because the two are almost never stored in the same format.

The critical asymmetry: keyword decks and MADYMO XML are human-readable and editable; binout and ERF are binary and must be read through an API or a converter. Any integration pipeline therefore has two distinct problems — mapping model topology and mapping result channels.

MADYMO XML: hierarchical and self-describing

MADYMO XML represents the model as a tree. A minimal restraint fragment looks like this:

<SYSTEM name="occupant">
  <BODY name="torso">
    <INERTIA Jxx="0.42" Jyy="0.51" Jzz="0.38"/>
    <MASS value="32.5"/>
  </BODY>
  <JOINT name="neck" type="BALL">
    <BODY_REF name="head"/>
    <BODY_REF name="torso"/>
  </JOINT>
  <CONTACT name="belt_torso" type="BELT">
    <SURFACE_REF name="torso_surface"/>
  </CONTACT>
</SYSTEM>

Because tags are named, XML is the easiest format to parse programmatically — but the schema is version-sensitive. A model written for MADYMO 7.6 may use attribute names that 2023.1 rejects or silently ignores. Always validate against the XSD shipped with your installed version before assuming a conversion succeeded.

LS-DYNA keyword: fixed-field discipline

Keyword decks are column-position sensitive. Each card is ten fields of eight characters. A misplaced decimal or a missing comma shifts every subsequent field and produces a deck that either fails to initialize or, worse, initializes with wrong values.

*MAT_ELASTIC
$#     mid        ro         e        pr        da        db
         1  7.85e-9  210000.0       0.3       0.0       0.0
*INITIAL_VELOCITY
$#    nsid        nid       vx        vy        vz       vxr       vyr       vzr
         0         0    15000.0      0.0      0.0       0.0       0.0       0.0

Note the unit system: mm, tonne, s, N. Mixing this with an SI-based MADYMO model is one of the most common integration errors, and it does not always produce an obvious crash — it produces plausible but wrong accelerations.

binout and ERF: binary result stores

LS-DYNA binout is a directory-structured binary file. You do not read it sequentially; you query it by block name. The standard Python route is lasso:

import lasso
b = lasso.dyna.Binout("d3plot_run.binout")
t = b.arrays[lasso.dyna.ArrayType.GLSTAT]
print(t["time"][:5])
print(t["kinetic energy"][:5])
# nodal history for node 1042
nod = b.arrays[lasso.dyna.ArrayType.NODE]
print(nod["node 1042"]["x acceleration"][:5])

PAM-CRASH ERF is similar in spirit but indexed by time step rather than by named block. Reading it typically requires the PAM-CRASH reader library or a vendor converter; the ERF header stores the time vector and a channel directory, and you must map channel IDs to physical quantities yourself. There is no universal naming convention — a channel labelled ACCX in one model may be AX in another.

Where conversions actually break

Four failure modes account for most integration pain:

1. Unit mismatch. MADYMO defaults to SI (m, kg, s); LS-DYNA crash decks are usually mm-tonne-s. A 15000 mm/s velocity becomes 15 m/s only if you divide by 1000 — and acceleration scales by 1000 as well.
2. Coordinate frame and sign convention. MADYMO uses a right-handed system with X forward; LS-DYNA vehicle decks often use X forward but some OEMs define X rearward. A sign flip in X turns a frontal pulse into a rearward one.
3. Time base misalignment. binout time starts at t=0 of the solver run; ERF may start at a pre-trigger offset. Correlating a belt force peak against a head acceleration peak requires both channels on a common, resampled time vector.
4. Topology loss. Converting an FE occupant to a multibody model discards mesh connectivity. Node IDs do not survive; you must re-establish which multibody body corresponds to which FE part.

A reproducible conversion check

Before trusting any cross-solver comparison, run a minimal sanity test. Take a single known channel — for example, the resultant acceleration of a head CG node — and verify it end-to-end.

1. Export the channel from binout as a CSV with time in seconds and acceleration in mm/ms².
2. Convert to SI: divide acceleration by 1000 to get m/s², or by 9810 to get g.
3. Export the same physical point from the MADYMO XML result and confirm the peak occurs within one time step of the binout peak.
4. If the peaks differ by more than 5% or are separated by more than 2 ms, stop and inspect units, frame, and time base before proceeding.

Practical guidance

Treat format conversion as a first-class engineering step, not a preprocessing afterthought. Parse XML and keyword decks with schema-aware tools, read binary results through the official API rather than reverse-engineered scripts, and always validate a known channel before scaling up to a full correlation study. When a conversion produces a curve that looks almost right, that is the most dangerous outcome — it usually means a unit or sign error that will survive into your analytics unless you explicitly test for it.