1. Crash simulation archives

Crash simulation is one of the most data-intensive activities in automotive engineering. A single full-vehicle frontal impact model may contain 8–15 million finite elements, and one solver run can produce tens to hundreds of gigabytes of output. Multiply that by hundreds of load cases, dozens of design iterations, and several vehicle programs, and an OEM quickly accumulates a petabyte-scale archive. The central engineering problem is no longer generating simulation data — it is finding the right run again. This chapter establishes the vocabulary and structure of that archive, and explains why conventional keyword search breaks down at this scale.

What Lives Inside a Crash Simulation Archive

An archive is not a single database. It is a federation of heterogeneous artifacts produced by different tools at different stages of the CAE workflow. Four families dominate:

• Model definition data — the input deck describing geometry, mesh, materials, connections, and boundary conditions. In LS-DYNA this is the .k / .key file (often split into includes such as main.k, mesh_*.k, materials.k); in PAM-CRASH it is the .pc input; Radioss uses _0000.rad with numbered includes.
• Solver output — d3plot state files (binary, time-stepped), binout* channel data, glstat and matsum ASCII summaries, nodout nodal time histories, and d3plot-adjacent files such as d3thdt.
• Post-processing and reporting artifacts — CAE session files, extracted curves, contour images, injury-criteria spreadsheets, and PowerPoint or PDF reports.
• Process and provenance records — job submission logs, solver version strings, license checkout records, and queue scheduler output.

These families differ in size, encoding, and lifetime. A d3plot family is huge and binary; a glstat file is small and human-readable; a report is small but semantically rich. Any search system must span all four without forcing users to know which family holds the answer.

File Formats and What They Imply for Search

Format determines what can be indexed cheaply and what requires parsing. The table below summarizes the practical consequences.

The key insight: the most valuable searchable content is often not in the largest files. Engineers rarely search for "the run whose d3plot is 240 GB." They search for "the 40 km/h ODB run on the 2023 front-end where the lower rail folded and B-pillar intrusion exceeded 120 mm." That description mixes load case, geometry, and physical outcome — none of which is a filename.

Metadata: The Bridge Between Files and Questions

Because raw solver output is opaque, archives rely on metadata captured at submission time and enriched afterward. A workable metadata schema for crash simulation typically includes:

• Identity — run ID, project, vehicle program, model revision, submission timestamp, submitting engineer.
• Load case — impact type (full frontal, offset deformable barrier, side MDB, rear, pole), impact speed, barrier type, impact angle, occupant configuration.
• Model context — solver and version, element count, unit system, key include list, material database revision.
• Execution — host, core count, wall-clock time, termination status, energy error ratio.
• Outcome — peak intrusion per measurement point, maximum acceleration, injury criteria (HIC, chest deflection, femur load), and a pass/fail flag against targets.

Outcome metadata is what makes an archive genuinely useful, but it is also the hardest to populate automatically. It requires post-processing each run and writing structured results back — a step that is frequently skipped under schedule pressure, which is precisely why so many archives degrade into unsearchable file dumps.

Why Keyword Search Fails

Conventional archive search matches literal strings against filenames and metadata fields. Three failure modes appear immediately:

1. Vocabulary mismatch. The engineer says "offset crash," the metadata says ODB_64, the report says "40% overlap deformable barrier." All three refer to the same test, and none of them match as strings.
2. Compositional queries. Real questions combine constraints across fields and files: "side impacts after the B-pillar gauge change where the door latch did not fail." No single field holds this; it is a join over load case, revision history, and outcome.
3. Implicit physical reasoning. "Runs where the front rail collapsed but the shock tower stayed intact" requires interpreting deformation results, not matching tokens.

Natural language search addresses these by mapping a free-text question onto a structured query over the metadata schema, then ranking results by relevance. The mapping step is where the engineering difficulty lives: the system must know that "offset crash" and ODB_64 are synonyms, that "B-pillar intrusion" is a numeric field with a threshold, and that "after the gauge change" is a temporal constraint on model revision.

A Concrete Metadata Record

The following example shows what a single well-formed archive entry looks like. Values are illustrative and represent a plausible mid-size sedan frontal offset case, not a measured result.

run_id:        FV-2023-FE-ODB64-00417
program:       MY2023 Sedan
model_rev:     BIW_r18 (B-pillar gauge 1.6 -> 1.8 mm)
load_case:     ODB_64  (40% overlap, deformable barrier)
impact_speed:  64 km/h
solver:        LS-DYNA smp s R13.1.0
elements:      9,842,110
units:         mm / ms / kg / kN
wall_clock:    6 h 12 m on 128 cores
termination:   normal, energy error 0.8%
outcome:
  lower_rail:      folded (buckle at Y=+412 mm)
  b_pillar_intrusion_max: 118 mm
  hic36:           612
  target_status:   PASS

Notice how much of this record is machine-generated. The submission wrapper writes identity, load case, solver, and execution fields. The post-processor writes the outcome block. Only the model revision note — "B-pillar gauge 1.6 → 1.8 mm" — is human-authored, and it is exactly the kind of context that makes a later query answerable.

What This Means for the Rest of the Course

Three conclusions follow from the structure above, and they shape everything that comes next. First, metadata quality determines search quality; a natural language interface cannot recover information that was never captured. Second, the schema must be designed for queries, not for storage — fields exist because engineers ask questions about them. Third, the mapping from language to schema is the core technical challenge, and it requires both linguistic handling (synonyms, thresholds, temporal references) and domain knowledge (what "folded" means physically, which fields encode it).

With this foundation — artifact families, format constraints, metadata fields, and the failure modes of keyword search — the next step is to examine how queries are actually expressed by engineers and what structure they share.