2. Simulation model architecture planning

A crash model that runs successfully on one engineer's workstation but fails on a colleague's machine, or that produces inconsistent results after a solver upgrade, is almost never a meshing problem. It is an architecture problem. Before the first shell element is created, the CAE lead must fix four decisions that will propagate through every subsequent phase of the project: the unit system, the coordinate convention, the file and directory structure, and the version-control strategy. Each decision is cheap to make at the start and expensive to reverse later.

2.1 Unit System Selection

LS-DYNA is unit-agnostic. It does not store a unit attribute on any keyword; it simply evaluates the numbers you supply. This is the single most common source of catastrophic modeling errors, because a model built in millimetre–tonne–second (mm–t–s) and accidentally loaded with a density in kg/mm³ will run without a single warning and produce a deformation field that is wrong by a factor of 10⁶ in mass.

The practical rule is to select one consistent system at project kick-off and record it in the model header. For full-vehicle crash simulation, the mm–t–s–N–MPa system is the de facto industry standard because it keeps mesh coordinates in the hundreds-to-thousands range, which is convenient for CAD exchange, and because stress in MPa maps directly to the yield strengths quoted on material datasheets.

Two derived quantities deserve explicit attention. First, *CONTROL_TIMESTEP and the computed critical time step are expressed in seconds regardless of the length unit, so a 1 µs step is written as 1.0e-6 in both systems. Second, gravity must be entered in the chosen length unit per second squared; using 9.81 in an mm–t–s model applies a load roughly 1000 times too small and will silently suppress settling behaviour in pre-crash or roof-crush load cases.

2.2 Coordinate Conventions

LS-DYNA itself imposes no global coordinate system, but crash models are almost always built to the SAE vehicle convention: X positive forward (toward the front of the vehicle), Y positive to the left when seated in the driver's seat, Z positive upward. This convention is assumed by barrier positioning, by occupant-restraint reference geometry, and by most post-processing macros that compute intrusion along the X axis.

Three conventions must be documented and held constant across the model:

• Global origin. Place it at the vehicle centreline, at ground level, at the front axle X-position. This makes symmetry checks trivial and keeps the barrier at a round X offset.
• Symmetry plane. If a half-model is used, the symmetry plane is Y = 0 and must be declared with *BOUNDARY_SPC_SET constraining Y-translation and X- and Z-rotation on the centreline nodes. Confirm the constraint set covers the full length of the trimmed body, not just the front structure.
• Initial velocity direction. For a frontal impact, the vehicle moves in +X toward a fixed barrier, so *INITIAL_VELOCITY carries a positive VX. For a moving deformable barrier (MDB) side impact, the barrier carries the velocity and the vehicle is initially at rest. State which body is moving in the model header; reversing this by mistake produces a model that runs to termination with almost no deformation.

Rotational sign conventions follow the right-hand rule about each axis. When a suspension or steering component is defined with local coordinates, record the local-to-global transformation in the assembly notes so that a later reviewer can verify that a toe angle of +0.5° corresponds to the intended direction.

2.3 File Organization

A crash model is not one file. A typical full-vehicle model is assembled from 40 to 200 include files, and the directory layout determines whether a change can be traced and reverted. The recommended structure separates the master deck, the subsystem includes, the material library, and the run outputs.

project_vehicle_crash/
├── master/
│   ├── main_frontal.k          # *INCLUDE tree root, control cards
│   └── main_side_mdb.k
├── subsystems/
│   ├── biw/
│   │   ├── body_front.k
│   │   ├── body_underbody.k
│   │   └── closures.k
│   ├── chassis/
│   │   ├── suspension_front.k
│   │   └── steering.k
│   └── restraints/
│       ├── airbag_driver.k
│       └── seatbelt_pretensioner.k
├── materials/
│   └── mat_library_v3.k        # *MAT_024, *MAT_098, *MAT_187 cards
├── connections/
│   ├── spotwelds_front.k        # *CONSTRAINED_SPOTWELD
│   └── adhesives.k
├── runs/
│   └── 2024-06-12_frontal_v07/
│       ├── d3plot
│       ├── glstat
│       └── run.log
└── docs/
    └── model_notes.md           # unit system, origin, version log

The master deck should contain only *CONTROL_* cards, *DATABASE_* cards, the *INCLUDE statements, and the initial velocity and boundary conditions. Keeping control cards in one place means a termination-time change for a sensitivity study touches exactly one file. Subsystem files should be self-contained: a subsystem that references a material ID defined in another subsystem will break when that subsystem is replaced.

Material IDs and part IDs must be allocated in blocks and recorded. A workable scheme assigns 1000–1999 to BIW steel, 2000–2999 to closures, 3000–3999 to chassis, and 4000–4999 to restraints. When two engineers merge work, block allocation prevents the silent ID collision that otherwise overwrites one material definition with another.

2.4 Version Control for LS-DYNA Models

Keyword files are plain text and diff cleanly, which makes Git or a comparable system entirely practical. The obstacles are binary artefacts and large result files, both of which must be excluded.

A minimal .gitignore for a crash project:

runs/
*.d3plot
*.d3plot*
*.binout*
*.glstat
*.matsum
*.rcforc
*.nodout
*.log
*.key#
*~

Commit the keyword decks, the material library, the connection definitions, and the model notes. Do not commit solver output. If a result must be archived for a milestone, store it outside the repository on shared storage and record the commit hash in the milestone record.

Two practices make the history useful. First, tag every model that has been correlated against a physical test, for example frontal_v07_correlated, so that the exact deck behind a validated result can be recovered. Second, write a commit message that names the change and its motivation, not the file touched: reduce front rail gauge 1.8 to 1.6 mm to match BOM rev C is recoverable; update model is not.

2.5 How the Decisions Interlock

These four choices are not independent. The unit system determines the numeric values in the material library; the coordinate convention determines the sign of the initial velocity and the symmetry constraints; the file structure determines which include owns each material and connection definition; and the version-control strategy determines whether a correlated model can be reproduced six months later. The diagram below shows how a single decision propagates into the assembled deck and where a mistake first becomes visible.

The diagram is deliberately read from left to right: each architectural decision feeds the assembled deck, the deck feeds the solver, and any inconsistency surfaces as a specific, diagnosable symptom rather than a generic error. When a run behaves unexpectedly, the first action is not to adjust contact parameters but to verify that the four decisions above are internally consistent and correctly recorded in model_notes.md.

2.6 Model Notes Template

The following header block should be committed alongside the master deck. It is short enough to maintain and complete enough to answer the questions that arise during correlation and review.

# Model Notes — Vehicle Frontal Crash
units:            mm, tonne, s, N, MPa
origin:           vehicle centreline, ground level, front axle X = 0
axes:             +X forward, +Y left, +Z up (SAE)
symmetry:         none (full model)
moving body:      vehicle, VX = +15556 mm/s (56 km/h)
barrier:          rigid wall, fixed, X = 2500 mm
solver:           LS-DYNA R13.1 smp d R13.1.1
termination:      0.120 s
mass (total):     1.842 t
part ID blocks:   BIW 1000-1999, closures 2000-2999,
                  chassis 3000-3999, restraints 4000-4999
material lib:     materials/mat_library_v3.k
correlated tag:   frontal_v07_correlated
last updated:     2024-06-12

Filling this block takes ten minutes. Reconstructing the same information from a deck that has been edited by four engineers over three months takes considerably longer, and the reconstruction is frequently wrong. Treat the model notes as a deliverable, not as documentation overhead.