2. LS-DYNA simulation workflow fundamentals

Before any AI model can learn from LS-DYNA simulations, the simulation data itself must be produced in a controlled, reproducible, and machine-readable way. This chapter establishes the end-to-end mechanics of an LS-DYNA run: how a keyword input deck is structured, how the solver is invoked and monitored, and which output formats are relevant when the goal is to build a training dataset rather than to answer a single engineering question. The emphasis is deliberately on the parts of the workflow that a data engineer must control — file naming, output cadence, and result extraction — because these determine whether the resulting dataset is usable at scale.

Anatomy of a Keyword Input Deck

An LS-DYNA model is described entirely by a text file (conventionally main.k or jobname.k) composed of keyword blocks. Each block begins with a *-prefixed keyword line, optionally followed by parameter lines and data cards whose column layout is fixed-width. The deck is order-sensitive in a few places (for example, *CONTROL cards must precede the parts they govern) but is otherwise a flat collection of blocks that the solver parses sequentially.

A minimal deck for a data-generation run typically contains the following block families:

• Control blocks — *CONTROL_TERMINATION (end time), *CONTROL_TIMESTEP (time-step scaling and TSSFAC), *CONTROL_ENERGY (hourglass and sliding energy tracking), and *CONTROL_OUTPUT (ASCII output switches).
• Database blocks — *DATABASE_BINARY_D3PLOT (state dumps at fixed intervals), *DATABASE_ASCII_* (nodal, element, and global time-history output), and *DATABASE_HISTORY_NODE / *DATABASE_HISTORY_SOLID for tracked quantities.
• Material and section blocks — *MAT_* and *SECTION_* defining constitutive behaviour and shell/solid thickness.
• Part and mesh blocks — *PART, *ELEMENT_SHELL, *ELEMENT_SOLID, *NODE.
• Contact and boundary blocks — *CONTACT_AUTOMATIC_SINGLE_SURFACE, *BOUNDARY_PRESCRIBED_MOTION_*, *INITIAL_VELOCITY_*.

For dataset generation, the two most consequential blocks are *CONTROL_TERMINATION and *DATABASE_BINARY_D3PLOT. The termination time sets the physical duration of each simulation; the D3PLOT interval (DT) sets how many state snapshots are written. A run with TERMINATION = 0.02 s and DT = 0.001 s yields 20 state dumps — a natural unit of "one simulation = 20 labelled frames" for a temporal model.

*CONTROL_TERMINATION
$#  endtim    endcyc     dtmin    endeng    endmas
     0.020         0       0.0       0.0       0.0
*DATABASE_BINARY_D3PLOT
$#      dt      lcdt     beam     nplt     psid
     0.001         0         0        0         0
*DATABASE_ASCII_NODE_FORCE
$#      dt    binary      lcur     ioopt
     0.001         0         0         1

Note the fixed-width column convention: the $# lines are comments that document the field order, and the numeric lines must align to those columns. Misaligned fields are the single most common cause of a deck that parses without error but produces physically wrong results — for example, a DT value landing in the LCDT column silently disables D3PLOT output.

Solver Execution and Monitoring

LS-DYNA is invoked from the command line. The exact executable name depends on the installation (ls-dyna_smp_d_R11_1_0, lsdyna, or a wrapper script), but the argument pattern is stable:

lsdyna i=main.k ncpu=8 memory=2000m jobid=run_001

Here i= names the input deck, ncpu= sets the shared-memory thread count, memory= requests the initial memory pool, and jobid= sets the output prefix. The solver writes a family of files sharing that prefix: run_001.out (the human-readable log), run_001.d3plot (binary state data), run_001.messag (diagnostics), and any ASCII history files requested by *DATABASE_ASCII_* blocks.

Monitoring a run means reading run_001.out as it grows. The critical lines are the time-step report (which should remain stable; a collapsing time step signals element distortion or contact instability), the energy summary (hourglass energy should stay below roughly 5–10% of internal energy), and the termination message. A run that ends with Normal termination is usable; one that ends with Error termination must be excluded from the dataset or re-run after fixing the deck.

Output Formats Relevant to Data Generation

LS-DYNA produces three output families that matter for AI training data, and they differ sharply in cost and usability:

The practical rule is to request only what the model needs. A surrogate model predicting peak acceleration at a handful of nodes does not require full-field D3PLOT dumps; enabling them multiplies storage by orders of magnitude and slows I/O. Conversely, a model that learns stress fields cannot be trained from ASCII history alone. The output configuration is therefore a dataset-design decision, not an afterthought.

Workflow Overview

The diagram below traces a single simulation from deck to dataset record, showing where the data engineer intervenes and which artefacts are retained.

The dashed path from the output artefacts to the dataset record indicates that only a subset of outputs is retained — typically the D3PLOT frames plus the scalar histories that serve as labels. The solid path through the quality gate is the acceptance route; failed runs are re-run after deck correction rather than silently included.

Practical Considerations for Reproducible Data Generation

Three habits make the difference between a dataset and a pile of files. First, parameterise the deck: keep the geometry and material blocks fixed and drive the varying quantities (impact velocity, thickness, material constants) from a template so that each run differs only in the intended parameter. Second, version the deck: store the exact .k file alongside each run's outputs, because a deck edited after the fact cannot be reconstructed from the binary results. Third, record the solver version: LS-DYNA results can shift subtly between releases, and a dataset mixing R11 and R13 outputs without a version tag is difficult to audit.

With the deck structure, execution pattern, and output families understood, the next step is to design the parameter sweep and the extraction pipeline that turn these individual runs into a coherent, labelled dataset. The mechanics described here — fixed-width cards, jobid-prefixed outputs, and termination-based quality gating — are the foundation on which that pipeline is built.