2. PAM-CRASH model architecture for production

A production-grade PAM-CRASH model is not a single input file. It is a structured, version-controlled assembly of decks, includes, and material libraries that must remain traceable from the first CAD release to the final sign-off run. This section defines the architecture that makes that traceability possible: how decks are organized, how the include hierarchy is layered, how unit systems are locked, and how the assembled model is versioned so that any result can be reproduced exactly.

Deck Organization: One Master, Many Modules

The recommended production layout separates the model into a thin master deck and a set of functional module decks. The master deck contains only control cards, unit declarations, include statements, and run-level switches. It contains no geometry, no mesh, and no material data. Every physical subsystem — body-in-white, closures, powertrain, suspension, interior, barrier, dummy, and restraint — lives in its own module deck.

A typical directory structure for a frontal impact program looks like this:

model_root/
  master/
    run_main.key
    units.inc
    controls.inc
  modules/
    01_biw/
      biw_mesh.inc
      biw_props.inc
    02_closures/
      hood.inc
      doors.inc
    03_powertrain/
      engine.inc
      mounts.inc
    04_suspension/
      front_susp.inc
      rear_susp.inc
    05_interior/
      seats.inc
      ip.inc
    06_restraints/
      belts.inc
      airbags.inc
    07_barrier/
      barrier_rigid.inc
    08_dummy/
      dummy_hybrid3.inc
  library/
    materials/
      steel_hsla.lib
      aluminum.lib
    sections/
      sections_std.lib
  runs/
    R2024_11_05_baseline/
    R2024_11_12_seat_update/

The master deck references modules through include statements in a fixed order. That order matters: nodes and elements must exist before they are referenced by constraints, and contact definitions must appear after all surfaces are defined. A stable include order is therefore part of the architecture, not an incidental detail.

Include Hierarchy and Resolution Rules

PAM-CRASH resolves includes relative to the working directory of the solver, not relative to the including file. In production this is a frequent source of failure when a model is moved between machines. The standard mitigation is to declare a single root variable and build every include path from it, or to run the solver from model_root/ and use paths relative to that root.

The include hierarchy should be shallow — three levels maximum. A deep chain of includes makes it impossible to answer "which file defines this element?" without opening every file. The recommended layering is:

• Level 0 — master: run_main.key, includes units, controls, and the module list.
• Level 1 — modules: one include per subsystem, each self-contained.
• Level 2 — library: material and section libraries included by modules, never by the master.

Modules must not include each other. If the suspension needs a material from the library, it includes the library file directly. Cross-module includes create hidden coupling and break independent versioning.

Unit System: Declare Once, Verify Everywhere

PAM-CRASH does not enforce a unit system. It computes with whatever numbers you provide. A model that mixes millimetres with metres, or tonnes with kilograms, will run to completion and produce plausible-looking but wrong results. The only defence is a declared, documented, and verified unit system.

The two common production systems are:

System A is the de facto standard for automotive crash models because mesh coordinates are naturally in millimetres. The critical check is density: steel at 7.85e-9 t/mm³, not 7850. A density off by 10⁹ produces a model that either explodes or barely moves.

Verification is done with a single-element or single-part check run before the full assembly. Apply a known load, compare the computed displacement or frequency against the hand calculation, and confirm the unit system is consistent. This takes minutes and prevents days of debugging.

Version-Controlled Model Assembly

Version control for CAE models is not the same as version control for source code. Binary result files, large meshes, and solver outputs do not belong in the repository. The production pattern is to version the text decks and the assembly manifest, and to store meshes and results in a separate artifact store referenced by hash.

Each run directory contains a manifest that records exactly which revision of each module was used:

# runs/R2024_11_12_seat_update/manifest.yaml
run_id: R2024_11_12_seat_update
solver: PAM-CRASH 2024.0
units: mm-tonne-s
modules:
  biw:        git:abc1234
  closures:   git:def5678
  powertrain: git:abc1234
  suspension: git:abc1234
  interior:   git:9ab0cde
  restraints: git:9ab0cde
  barrier:    git:abc1234
  dummy:      git:abc1234
library:
  materials:  git:1122334
  sections:   git:1122334
mesh_artifacts:
  biw_mesh:   sha256:7f3a...
  dummy_mesh: sha256:2c9b...

The manifest is the single source of truth for reproducibility. Given a manifest, the assembly script checks out the exact revisions, resolves the include paths, and produces a runnable master deck. No manual file copying, no "latest version" ambiguity.

Assembly Workflow and Verification

The assembly workflow has four stages: checkout, resolve, validate, and freeze. Checkout pulls the revisions named in the manifest. Resolve expands the include hierarchy into a single flattened deck for the solver. Validate runs structural checks — orphan nodes, duplicate IDs, missing materials, unit consistency, and include path resolution. Freeze writes the flattened deck and its hash into the run directory, making the run immutable.

Validation is where most production defects are caught. The checks that matter most are: every element references an existing property, every property references an existing material, no duplicate node or element IDs across modules, and all include paths resolve from the run root. A model that passes these checks is structurally sound; whether it is physically correct is a separate question answered by the solver.

Practical Failure Modes and Their Symptoms

Three failure modes account for most production assembly problems. First, unit mismatch: the model runs but displacements are off by orders of magnitude, or the time step collapses to near zero. Check density and Young's modulus first. Second, include path failure: the solver reports a missing file, or worse, silently reads a stale file from a different directory. Always run from model_root/ and verify resolved paths in the validation log. Third, duplicate IDs: two modules define the same node or element ID, and the solver overwrites one with the other. The symptom is a part that appears to have no stiffness or a contact that never activates. The validation stage must check ID ranges per module and enforce non-overlapping allocation.

ID range allocation is part of the architecture. Assign each module a fixed numeric block — for example, BIW nodes 100000–199999, closures 200000–299999, and so on. This makes duplicates impossible by construction and makes it trivial to trace any element back to its owning module.

Summary

A production PAM-CRASH model is an assembly, not a file. The master deck declares units and controls; module decks own geometry and properties; the library owns materials and sections; the manifest records exact revisions; the assembly pipeline checks out, resolves, validates, and freezes. Unit systems are declared once and verified with a single-element check. ID ranges are allocated per module. Include paths are relative to a single root. Follow this architecture and any result can be reproduced from its manifest; skip it and every result becomes an unrepeatable one-off.