3. Python environment setup for LS-DYNA automation

A reliable LS-DYNA automation workflow depends on a Python environment that can locate the solver, parse keyword decks, manipulate large result files, and run consistently across machines. This chapter defines the required libraries, a directory convention that keeps decks and outputs traceable, and the execution environment configuration that ties Python to the LS-DYNA installation. The goal is a reproducible setup: any engineer cloning the project should be able to run the same scripts and obtain the same directory structure and solver invocation.

3.1 Required Libraries and Their Roles

LS-DYNA automation rarely needs a heavy framework. A small, stable set of libraries covers deck editing, batch execution, result parsing, and reporting. The table below lists the core dependencies and why each is needed.

Install these into a dedicated virtual environment rather than the system interpreter. This isolates LS-DYNA automation from other projects and makes the environment reproducible:

python -m venv .venv
# Windows
.venv\Scripts\activate
# Linux / macOS
source .venv/bin/activate

pip install lasso-python numpy pandas pyyaml jinja2

Pin versions in a requirements.txt once the workflow is validated. LS-DYNA result formats are stable, but lasso-python and numpy release frequently; an unpinned environment can break a working parser after an upgrade.

3.2 Directory Conventions

A consistent directory layout is what makes batch runs auditable. Each simulation case should own a self-contained folder, and shared assets should live outside individual runs. The following convention is used throughout this course:

lsdyna_project/
├── config/
│   └── config.yaml          # solver path, license, run parameters
├── templates/
│   └── deck_template.k      # Jinja2 keyword template
├── cases/
│   └── case_001/
│       ├── input/
│       │   ├── model.k      # generated deck
│       │   └── include/     # *INCLUDE files
│       ├── run/
│       │   ├── d3plot
│       │   ├── binout
│       │   └── glstat
│       └── meta.json        # parameters and status for this case
├── scripts/
│   ├── generate_deck.py
│   ├── run_solver.py
│   └── extract_kpi.py
└── reports/
    └── summary.csv

Two rules matter most. First, the solver must be launched with its working directory set to cases/<case>/run/, because LS-DYNA writes d3plot, binout, and messag into the current directory. Second, generated decks belong in input/, never in run/, so that a re-run does not overwrite the source deck. Keeping meta.json beside each case records the exact parameters used, which is essential when comparing dozens of runs.

3.3 Execution Environment Configuration

The Python process needs three pieces of information: where the solver executable is, how many cores to use, and where the license server lives. Centralize these in config/config.yaml so scripts never hard-code machine-specific values:

solver:
  executable: "C:/LSDYNA/smp_d_R11_1_winx64_ifort131.exe"
  ncpu: 4
  memory_mb: 2000
  license:
    server: "27000@license-host"
    lstc_file: "C:/LSDYNA/license/lstc_file"

paths:
  project_root: "."
  cases_dir: "cases"
  reports_dir: "reports"

A loader function reads this file and exposes a typed configuration object. The solver invocation itself is built from these values. On Windows with the SMP executable, the command is:

smp_d_R11_1_winx64_ifort131.exe i=model.k ncpu=4 memory=2000m

On a Linux cluster with the MPP executable, the same run is launched through MPI:

mpirun -np 4 ls-dyna_mpp_d_R11_1_linux_x64_ifort i=model.k

The Python wrapper should set the working directory, build the argument list, and capture both the exit code and the tail of messag. A non-zero exit code or the string Error termination in messag indicates a failed run; a normal completion ends with Normal termination. Recording this status in meta.json lets downstream scripts skip failed cases automatically.

3.4 Verifying the Environment

Before running any real case, verify the setup with a minimal smoke test. The following script checks that the solver is reachable, that the required libraries import, and that a trivial deck runs to completion:

import subprocess, yaml
from pathlib import Path
import lasso, numpy, pandas

cfg = yaml.safe_load(Path("config/config.yaml").read_text())
exe = cfg["solver"]["executable"]

result = subprocess.run([exe, "i=smoke.k", "ncpu=1"],
                        cwd="cases/smoke/run",
                        capture_output=True, text=True)
print("exit code:", result.returncode)
print(result.stdout[-500:])

Expected observable outcome: exit code 0, and the last lines of messag contain Normal termination. If the solver cannot be found, subprocess raises FileNotFoundError; if the license is unavailable, LS-DYNA exits early with a license error in messag. Both symptoms point back to config.yaml, which is exactly why the configuration is centralized.

The diagram below summarizes how the Python environment, configuration, directory layout, and solver interact during a single automated run.

With the environment verified, the remaining chapters can focus on deck generation, batch execution, and result extraction without revisiting setup. The key discipline is that every machine-specific value lives in config.yaml, every case owns its own directory, and every run records its status — so that a batch of fifty crash simulations remains as traceable as a single one.