2. PAM-CRASH user environment and workflow

PAM-CRASH is not a single executable but a toolchain. A complete crash simulation passes through four distinct environments: a pre-processor for model assembly, a job launcher for solver control, the explicit solver itself, and a post-processor for result interpretation. Understanding where each environment begins and ends — and what data crosses the boundary — is the difference between a reproducible workflow and a folder full of orphaned files.

The canonical chain is Visual-Environment → PAM-CRASH solver → PAM-VIEW. Visual-Environment (VE) is the integrated GUI that hosts model setup, keyword editing, and job submission. PAM-VIEW is the results reader, typically launched from within VE but also runnable standalone. The solver is a batch process; it never opens a window, and it communicates only through files.

Model setup in Visual-Environment

A PAM-CRASH input deck is organized into functional blocks, and VE exposes them as a structured tree rather than a raw text file. The essential blocks for a frontal impact model are:

• Control cards — termination time, time-step control, output frequency.
• Material definitions — elastic-plastic, foam, spot-weld, and failure models.
• Part and element data — shell, solid, and beam connectivity with thickness and integration rules.
• Contact interfaces — self-contact, surface-to-surface, and tied connections.
• Boundary and initial conditions — constraints, prescribed velocities, gravity.

In VE, the practical sequence is: import CAD or an existing mesh, assign materials and properties through the property editor, define contacts, then apply the barrier or wall and the initial velocity. A typical frontal impact setup uses an initial velocity of VX = -56 km/h (approximately -15555 mm/s) applied to the vehicle body, with the rigid barrier fixed. Note the sign convention: PAM-CRASH uses a right-handed global coordinate system, and the vehicle travels in the negative X direction toward a barrier at the origin. This convention must be stated once and held consistently through the deck, the contact definitions, and the post-processing views.

Two setup details cause most early failures. First, unit consistency: PAM-CRASH is unit-agnostic, so a mixed deck (mm, ms, kg, kN) must be used everywhere — a single material card in SI units will produce a time step that is wrong by orders of magnitude. Second, initial penetration in contact interfaces: if slave nodes start inside the master surface, the solver generates large artificial contact forces at t = 0 and the model may blow up within the first few milliseconds.

Job submission and solver execution

VE writes the deck as a .pc input file plus a run directory. Submission can be done from the VE job panel or from a shell. A minimal batch invocation looks like:

pamcrash -i frontal_impact.pc -o frontal_impact.out -t 4 -m 16G

Here -i is the input deck, -o the main output log, -t the number of threads, and -m the memory allocation. On HPC clusters the same command is wrapped in a scheduler script (SLURM, PBS, LSF). The solver then produces a family of files, and knowing which is which prevents a great deal of confusion:

During execution, monitor three quantities in the .out file. The time step should remain stable; a sudden drop usually means an element is being crushed to near-zero size. The energy balance — kinetic, internal, and hourglass energy — should show hourglass energy below roughly 5% of internal energy; higher values indicate under-integrated elements are behaving too softly. The added mass from time-step scaling should stay near zero; if the solver has scaled mass to preserve a large time step, the physics is compromised.

Post-processing with PAM-VIEW

PAM-VIEW reads the .erf and .dsy files. The workflow is: load the animation file, select the state variable (von Mises stress, plastic strain, displacement magnitude), animate through time, then extract time-history curves at specific nodes or sections. For a frontal impact, the standard deliverables are the barrier force–time curve, the B-pillar acceleration–time curve, and the intrusion contour at the occupant compartment.

Time-history data from the .dsy file is usually filtered before comparison with test data. The SAE J211 channel filter class (CFC 60 for structural acceleration, CFC 180 for occupant response) is applied in PAM-VIEW's curve operations. Reporting unfiltered peaks is a common and serious error, because the raw signal contains high-frequency noise that no physical test would record.

A reproducible run checklist

The following checklist captures the minimum information needed to reproduce a run. It is deliberately short; each item corresponds to a failure mode observed in practice.

When a run fails, the diagnostic order is fixed: read the last 50 lines of the .out file for the error code, check whether the time step collapsed, then inspect the animation at the last written state to locate the offending element. In the great majority of cases the root cause is a single distorted element, an initial penetration, or a material card with an unrealistic tangent modulus — all of which are visible in the pre-processor before the job is ever submitted.

The workflow is therefore not a linear pipeline but a loop. Post-processing reveals correlation gaps, those gaps are corrected in Visual-Environment, and the deck is resubmitted. Treating the four environments as one continuous system, with explicit data handoffs at each boundary, is what makes the process controllable rather than merely repeatable.