1. High-throughput crash simulation platfor

Crash simulation is one of the most computationally expensive workloads in automotive CAE. A single full-vehicle frontal impact model routinely contains 8–15 million shell and solid elements, runs for 120–150 ms of physical time, and requires 12–48 hours of wall-clock time on a few hundred CPU cores. A modern vehicle program, however, does not need one such run — it needs thousands. Load cases multiply across frontal, offset, side, rear, pole, and pedestrian scenarios; design iterations multiply again across body-in-white variants, material cards, and restraint tuning. The result is a throughput problem: the engineering question is no longer "can we run a crash simulation?" but "how many validated crash simulations can we deliver per day, per week, and per program, at acceptable cost and traceability?"

High-throughput crash simulation platform engineering is the discipline of building the software, hardware, and process infrastructure that turns a validated LS-DYNA or Pam-Crash model into a continuously flowing, reproducible, and auditable stream of simulation results. It sits at the intersection of HPC cluster operations, CAE workflow automation, data management, and solver-specific domain knowledge. This chapter defines the scope of that discipline, states its core objectives, and presents the reference system architecture that the remaining chapters will build out in detail.

Scope: What the Platform Owns and What It Does Not

A common failure mode in platform projects is scope creep into solver physics or CAD authoring. The platform is not responsible for mesh quality, material model calibration, or contact definition correctness — those remain the domain of the CAE engineer. What the platform owns is everything between "a model revision is frozen" and "a trustworthy result set is available for post-processing and reporting." Concretely, that boundary includes:

• Model intake and versioning. Accepting a keyword deck (e.g., model_v17.k), hashing it, recording its include-tree, and binding it to a revision identifier that never changes.
• Job specification and parameterization. Translating a load case plus a design-of-experiments point into a concrete solver input — for example, overriding *INITIAL_VELOCITY magnitude, *MAT_024 yield stress, or barrier position via include-file substitution.
• Scheduling and resource allocation. Mapping each job to a queue, a core count, a memory tier, and a license token, then dispatching it to the cluster.
• Execution monitoring and fault handling. Detecting negative-volume errors, mass-scaling warnings, and license timeouts, and deciding automatically whether to retry, requeue, or quarantine.
• Result harvesting and metadata capture. Extracting d3plot, binout, and glstat artifacts, computing key performance indicators (intrusion, HIC, peak acceleration), and storing them alongside the job record.
• Traceability and reporting. Answering, months later, "which model revision, which solver build, and which parameters produced this curve?"

Out of scope: mesh generation, CAD geometry repair, solver source-code modification, and final engineering sign-off. The platform delivers evidence; engineers deliver decisions.

Core Objectives

Five objectives define success for the platform, and they are frequently in tension with one another, which is why they must be stated explicitly rather than assumed.

Throughput without reproducibility is worthless — a fast pipeline that produces non-repeating numbers cannot support design decisions. Reproducibility without traceability is also weak, because a result that cannot be attributed to a specific model revision and solver build cannot be defended in a design review. Resource efficiency matters because crash jobs are the largest single consumer of CAE cluster capacity in most OEMs, and license tokens for LS-DYNA MPP are a hard constraint: a 512-core job consumes 512 tokens, so a 4,000-token pool supports at most seven such jobs concurrently regardless of how many cores are idle.

Reference System Architecture

The platform is best understood as five cooperating layers with a shared metadata backbone. The diagram below shows the layers, the primary data objects that cross each boundary, and the control path that returns status and KPIs to the engineer.

Two properties of this architecture deserve emphasis. First, the metadata backbone is shared across all five layers: the same job ID that the scheduler assigns is the key under which the KPI record is stored, so a query on a job ID returns the model revision, the parameter overrides, the solver build, the resource consumption, and the resulting KPIs in one join. Second, the feedback path is not optional. Without it, the platform is a batch submission script; with it, the platform can answer capacity-planning questions ("how many 512-core jobs can we sustain next quarter?") and quality questions ("which solver build introduced the mass-scaling regression?") from the same data.

A Concrete Throughput Example

To make the objectives tangible, consider a mid-size SUV program with a 9.2-million-element frontal ODB model. On the reference cluster, one run on 384 cores completes in approximately 14 hours and produces a d3plot set of about 180 GB. Suppose the program needs 40 design variants across 6 load cases, with 3 repeat runs per variant for statistical confidence — 720 jobs. At 14 hours each and 7 concurrent 384-core jobs (limited by a 2,688-token allocation), the naive serialized time is 720 × 14 / 7 ≈ 1,440 hours, or 60 days. The platform's job is to compress that number by three levers: raising concurrency through better token scheduling, cutting per-job time through solver and decomposition tuning, and eliminating wasted runs through early fault detection. A realistic target after platform engineering is 18–22 days for the same 720 jobs, with every job traceable and every KPI reproducible.

What Comes Next in This Course

The remaining chapters build each layer in turn: model intake and hashing, parameterization and DOE binding, scheduler integration and license management, solver execution monitoring, KPI extraction, provenance storage, and dashboarding. Each chapter follows the same principle established here — define the object, define the operation, define the observable result, and define how to tell success from failure.