2. PAM-CRASH solver environment setup

An airbag simulation is only as reliable as the environment that runs it. Before a single element is defined, the analyst must establish a working PAM-CRASH solver environment: a valid license must be reachable, the solver binary must be invocable from a controlled working directory, the input deck must be organized so that the solver can resolve every referenced file, and output requests must be scoped so that the resulting data is both sufficient for validation and manageable in size. This chapter walks through each of these four concerns in the order they are typically addressed on a real project.

Licensing: Making the Solver Reachable

PAM-CRASH is a licensed commercial solver. In most installations the license is served by a FlexLM-style license manager, and the client machine locates it through an environment variable. On Linux the typical variable is PAM_LMD_LICENSE_FILE or LM_LICENSE_FILE, pointing at a port and host:

export PAM_LMD_LICENSE_FILE=27000@pam-license.internal
export PAM_CRASH_HOME=/opt/esi/pamcrash/2023.0
export PATH=$PAM_CRASH_HOME/bin:$PATH

Two failure modes dominate here. First, the license server may be reachable but the specific feature for the solver (for example, the explicit crash solver versus the implicit solver) may be exhausted or absent; the solver then exits immediately with a license error rather than a model error. Second, a firewall may block the license port even though the host resolves. A quick diagnostic is to query the license server directly before launching a job:

lmutil lmstat -a -c 27000@pam-license.internal

If the feature line shows no available seats, the job will not start regardless of how correct the deck is. Confirm the feature name against the vendor documentation for your release, because feature strings change between versions. On Windows the same variables are set through the system environment dialog or a launch script; the principle is identical.

Invoking the Solver

PAM-CRASH is normally invoked from a dedicated run directory, not from the directory containing the input deck, so that scratch files and outputs do not pollute the source tree. A typical invocation passes the input file and an output prefix:

mkdir -p run/airbag_drop
cd run/airbag_drop
pamcrash -i ../../decks/airbag_drop.pc -o airbag_drop

The exact flag set depends on the release and on whether the job is run in serial or parallel. For shared-memory runs the thread count is usually controlled by an environment variable such as OMP_NUM_THREADS; for distributed runs an MPI launcher wraps the solver. Always capture the solver's standard output to a log file, because the license check, the model echo, and the first warnings appear there before any results are written:

pamcrash -i ../../decks/airbag_drop.pc -o airbag_drop > airbag_drop.log 2>&1

A healthy start shows the version banner, the license feature granted, the number of nodes and elements read, and the initial time step. If the log stops after the banner, suspect licensing; if it stops after the element count, suspect the deck.

Organizing the Input Deck

Airbag decks reference several categories of files, and the solver resolves them relative to the run directory unless absolute paths are given. A reproducible layout keeps the source deck, the include files, and the run directory separate:

Use relative include paths anchored to the run directory, or set an include search path if the release supports it. Absolute paths make a deck non-portable and are a common cause of "file not found" errors when a colleague reruns the job on a different machine. Keep the inflator definition in its own include so that a single pressure curve can be swapped without touching the mesh.

Output Control

Output control is where airbag simulations most often go wrong, because the data needed for validation (bag pressure, bag volume, contact forces, occupant kinematics) is not the same as the data needed for a quick sanity check. PAM-CRASH separates output into time-history (curve) output and animation (state) output, each with its own frequency.

Time-history output should be requested at a fine interval for the quantities that drive the validation criteria. For a driver airbag, the essential curves are bag internal pressure, bag volume, and the force at the steering-column attachment. Animation output can be coarser, since it is used for visual review rather than numerical comparison:

THISTORY  /  DT = 0.0002   ; 0.2 ms curve interval
STATE     /  DT = 0.002    ; 2.0 ms animation interval

Requesting animation at the same fine interval as curves is a frequent mistake: it multiplies disk usage without improving the validation, and on large occupant models it can dominate the run time. A practical rule is to set the curve interval to resolve the fastest physical event (inflator discharge, typically sub-millisecond) and the animation interval to resolve the gross motion (a few milliseconds).

Finally, confirm that the output prefix is unique per run. Reusing a prefix overwrites previous results and destroys the evidence needed to compare a baseline against a modified deck. A naming convention that encodes the deck version and the run date, such as airbag_drop_v03_20240612, prevents this.

The diagram above summarizes the dependency chain: the license server authorizes the solver, the deck supplies the model, the run directory isolates the job, and the solver emits two distinct output streams at different frequencies. Each link is a potential point of failure, and each has a specific diagnostic. When a job fails, work through the chain in order—license, then deck resolution, then run directory, then output volume—rather than changing the model, because the environment is the more common culprit and the cheaper one to verify.