2. Prepare an LS-DYNA input deck for HPC submission

Why deck preparation is a separate step from submission

An LS-DYNA input deck that runs fine on a workstation can fail immediately on a cluster for reasons that have nothing to do with the physics: a referenced include file that exists only on the local disk, a unit system that was silently mixed between two submodels, or a solver feature that is unavailable in the licensed MPP executable. Catching these problems before the job enters the queue saves the walltime you would otherwise burn on a failed run and, more importantly, prevents a partially written d3plot from being mistaken for a completed analysis.

This case treats deck preparation as a validation pass with three independent checks — file references, unit consistency, and solver compatibility — followed by a cleanup step that produces a submission-ready directory. The checks are deliberately mechanical so they can be scripted and repeated for every job.

The three validation axes

The diagram below shows how a raw deck flows through the three checks and what each check is actually inspecting. Note that the checks are not sequential gates in the sense that a failure in one blocks the others; you want to collect all findings in a single pass so the deck is fixed once, not three times.

Check 1 — resolving every file reference

LS-DYNA resolves *INCLUDE paths relative to the directory from which the solver is launched, not relative to the file containing the card. On a cluster the launch directory is the job's working directory, which is almost never the directory where you built the model. Two failure modes dominate:

• Absolute paths such as *INCLUDE /home/jsmith/models/mesh.k — these break the moment the job runs under a different account or on a node where that home directory is not mounted.
• Nested relative paths such as *INCLUDE ../mesh/part01.k — these work locally but break when the submission directory is copied without preserving the parent structure.

A quick audit of the deck and all its includes:

# List every *INCLUDE target in the deck tree
grep -rhi '^\*INCLUDE' . | awk '{print $2}' | sort -u

# Flag absolute paths (should return nothing for a portable deck)
grep -rhi '^\*INCLUDE' . | awk '$2 ~ /^\// {print "ABSOLUTE:", $2}'

# Verify each referenced file exists relative to the run directory
grep -rhi '^\*INCLUDE' . | awk '{print $2}' | while read f; do
  [ -f "$f" ] || echo "MISSING: $f"
done

The cleanup step is to flatten the include tree into a single includes/ subdirectory and rewrite every *INCLUDE to a bare filename, so the deck is self-contained. If your model uses *INCLUDE_PATH, set it to . and keep all files in one directory.

Check 2 — unit consistency

LS-DYNA has no unit declaration; it simply interprets every number in whatever system you used. The classic failure is a mesh imported in millimetres while material cards were written in metres, producing a density that is off by 10⁹ and a stable time step that is either absurdly small (job never finishes) or absurdly large (immediate instability).

Pick one system and verify the magnitudes of a few anchor quantities. The table gives the expected order of magnitude for the two most common systems:

Spot-check the *MAT density and *PART or *SECTION thickness against this table. If density is 7.83e-9 but thickness is 0.002, you have a mixed deck. Also confirm that *CONTROL_TERMINATION ENDTIM is consistent: a 0.05 s event in the mm–tonne–s system is 0.05, not 5e-5.

Check 3 — solver compatibility

Before the deck reaches the queue, confirm it will run under the executable the cluster will actually launch. The relevant questions:

• MPP vs. SMP. Some keywords and contact options behave differently or are unsupported in MPP. If the job will run with lsdyna_mpp, check for cards that require SMP-only features and for any *CONTROL_MPP_DECOMPOSITION_* settings that assume a specific decomposition.
• License feature. Confirm the cluster's license includes the feature your deck needs (e.g., implicit, ALE, or a specific material model). A deck that references a licensed-only material will abort at initialization.
• Restart consistency. If this is a restart, verify that *STRESS_INITIALIZATION and the d3dump file match the original run's binary version and decomposition.

A cheap pre-flight is to run the deck through the solver's keyword checker (or a short NEND=-1 initialization-only run) on a compute node before submitting the full job. This catches unsupported cards and license errors in seconds rather than after a queue wait.

Producing the submission-ready directory

The output of the validation pass is a directory that can be copied to the cluster and submitted without further editing. A minimal, reproducible layout:

job_002/
├── main.k              # cleaned deck, all *INCLUDE rewritten to bare names
├── includes/           # flattened include files
│   ├── mesh.k
│   ├── materials.k
│   └── contacts.k
├── manifest.txt        # deck hash, file list, unit system, solver version
└── (no d3plot, d3dump, or *.out from previous runs)

Two cleanup rules matter here. First, remove any stale output files — a leftover d3plot from a previous attempt will be overwritten, but a leftover d3dump can silently be picked up by a restart card. Second, strip comments and trailing whitespace from the deck only if your workflow requires it; LS-DYNA tolerates them, but a clean deck makes the manifest hash stable and diffable.

Verification before you submit

You have a valid deck when all of the following hold:

1. The include audit returns no ABSOLUTE or MISSING lines.
2. Density, modulus, thickness, and gravity all fall in the same column of the unit table.
3. An initialization-only run on a compute node exits with Normal termination and no unsupported-keyword warnings.
4. The submission directory contains no output files from prior runs, and manifest.txt is present.

If the initialization run aborts, the error message usually names the offending card or the missing file directly; fix that single item and re-run the check rather than re-auditing the whole deck. Once the four conditions pass, the deck is ready for the batch script that will actually request resources and launch the solver.