1. End-to-end LS-DYNA automation landscape

LS-DYNA is rarely used as a standalone solver in production crash, drop, blast, or forming programs. A single design iteration typically involves CAD cleanup, meshing, keyword assembly, solver execution on a cluster, and post-processing of hundreds of gigabytes of results. When engineers drive each of these stages by hand, the cost is not only wall-clock time but also reproducibility risk: a model that ran successfully last week may fail today because a path changed, a license was busy, or a restart file was overwritten. End-to-end automation is the discipline of turning this chain into a controlled, repeatable pipeline that spans the engineer's workstation and the HPC cluster.

This chapter establishes the landscape for the rest of the course. It defines what "end-to-end" means in an LS-DYNA context, why organizations invest in it, where the boundary of a reasonable automation scope lies, and which technical challenges consistently dominate real deployments.

What "End-to-End" Actually Covers

A complete LS-DYNA automation pipeline spans five functional stages, each with distinct tooling and failure modes:

• Model preparation — parametric geometry or mesh generation, keyword file assembly from include files, unit consistency checks, and version control of the input deck.
• Job submission — translating a model plus a resource request into a scheduler job (Slurm, PBS Pro, LSF), including MPI rank count, memory per node, wall-clock limits, and license tokens.
• Solver execution — the LS-DYNA run itself, including restart handling, termination detection, and capture of the d3hsp, messag, and glstat files.
• Result extraction — parsing binout or ASCII output into scalar metrics (peak acceleration, intrusion, energy ratios) rather than leaving judgment to manual GUI inspection.
• Decision and feedback — comparing metrics against targets, triggering the next design point, and archiving the full provenance of the run.

The word "end-to-end" is meaningful only when all five stages are connected by machine-readable handoffs. A script that generates meshes but leaves submission to a human is partial automation; it removes one bottleneck while leaving the reproducibility problem intact.

Motivation: Why Organizations Automate

The business case rests on four pillars. Throughput is the most visible: a design-of-experiments study with 200 crash load cases is infeasible manually but routine when submission and extraction are automated. Reproducibility is the most valuable long-term: when every run records its input deck hash, solver version, rank count, and environment modules, a result can be reconstructed months later. Resource efficiency matters on shared clusters, where a job that requests 64 ranks but scales poorly wastes allocation for every other user. Engineer attention is the scarcest resource: automation converts hours of file shuffling into minutes of reviewing extracted metrics.

Scope Boundaries: What to Automate and What Not To

Automation scope should be drawn deliberately. The following table contrasts stages that are usually worth automating with those where human judgment should remain in the loop.

A common failure pattern is over-automation of the last row: pipelines that auto-approve designs based on a single scalar threshold produce confident but wrong conclusions. The defensible boundary is to automate measurement and flagging, and to keep acceptance decisions explicit and auditable.

Key Challenges in HPC-Integrated Workflows

Five challenges recur across nearly every LS-DYNA automation deployment.

1. Environment heterogeneity. The workstation where the deck is assembled and the compute node where it runs rarely share the same filesystem layout, module set, or LS-DYNA build. A deck that references include paths relative to a local directory will fail on the cluster unless paths are normalized at submission time. The practical fix is to stage inputs into a run directory on shared storage and rewrite include paths to be relative to that directory.

2. Scheduler semantics. Slurm and PBS differ in how they express rank placement, memory, and array jobs. A 200-case DOE maps naturally to a job array, but each array element must receive a distinct run directory and license token accounting. Getting this wrong produces silent overwrites — two cases writing to the same binout.

3. License contention. LS-DYNA licenses are a shared, finite resource. Automation that submits aggressively can starve interactive users or cause jobs to abort mid-run when tokens are reclaimed. Pipelines need a license-aware submission gate, not just a scheduler queue.

4. Failure detection. LS-DYNA can exit with code 0 while producing physically invalid results, or exit non-zero after writing partial output. Robust pipelines parse messag and d3hsp for warning signatures (negative volumes, excessive mass scaling, energy error) rather than trusting the exit code alone.

5. Data volume. A single crash model can produce tens of gigabytes of binout and animation data. Extracting metrics on the compute node and transferring only scalars back is usually far cheaper than moving raw results to the workstation.

A Minimal Reproducible Example

To make the landscape concrete, consider a two-case DOE on a Slurm cluster. The workstation script assembles each deck into its own directory and writes a manifest:

runs/
  case_A01/
    model.k          # assembled keyword deck
    manifest.json    # deck sha256, lsdyna version, rank count, targets
  case_A02/
    model.k
    manifest.json

The submission step reads each manifest and emits a job array element that stages the case directory, runs lsdyna_mpp with the recorded rank count, and parses binout on the node. A representative Slurm array line looks like:

sbatch --array=0-1 --nodes=2 --ntasks-per-node=32 \
       --mem=0 --time=04:00:00 run_case.slurm

Verification is observable rather than assumed: after completion, each case directory should contain a metrics.json with the extracted scalars, and the pipeline should confirm that the d3hsp file reports the expected termination message and that the energy ratio (total energy divided by initial energy) stays within a documented tolerance. A case that exits 0 but shows a rising energy ratio or a negative-volume warning is flagged for human review rather than accepted.

How the Rest of the Course Fits

The challenges above define the course structure. Subsequent chapters move from deck assembly and provenance capture, through scheduler integration and license-aware submission, into failure triage, metric extraction, and finally scaling studies that inform rank selection. Each stage is treated as an engineering artifact with inputs, observable outputs, and explicit acceptance criteria — because that is precisely what makes an end-to-end pipeline trustworthy rather than merely fast.