2. LS-DYNA solver fundamentals for verification
Verification of AI-generated training data against LS-DYNA requires more than running a deck and comparing numbers. The verifier must understand which solver decisions shape the output, because those same decisions determine whether a discrepancy is a genuine data error or an expected modeling difference. This chapter covers the three solver pillars that most strongly influence dataset generation: time integration (explicit vs. implicit), contact algorithms, and material models. For each, we focus on what the verifier must inspect, how to configure it reproducibly, and how to interpret observable outputs.
Explicit and Implicit Time Integration
LS-DYNA's explicit solver advances the solution with the central difference method. The displacement update at step n+1 depends only on quantities at steps n and n−1, so no system of equations is solved and no global stiffness matrix is assembled. Stability is conditional: the time step must satisfy the Courant–Friedrichs–Lewy (CFL) limit, approximately the smallest element characteristic length divided by the dilatational wave speed. For a steel part with a 2 mm solid element and a wave speed near 5000 m/s, the stable step is on the order of 0.4 µs. LS-DYNA reports the actual step in the d3hsp file and prints a warning when mass scaling is active to raise it.
The implicit solver instead solves K·Δu = f_ext − f_int at each increment, typically with a Newton–Raphson iteration and a direct or iterative linear solver. It is unconditionally stable for linear problems, so large steps are possible, but each step is far more expensive and convergence can fail for highly nonlinear contact or material behavior. For dataset generation, the choice is not stylistic: an explicit run and an implicit run of the same physical event will differ in step count, numerical damping, and contact treatment, and a verifier comparing an AI-produced result to a reference must confirm both used the same integration scheme.
*CONTROL_IMPLICIT_GENERAL with IMFLAG=1, it is implicit; if it relies on *CONTROL_TIMESTEP with a small DTINIT and no implicit controls, it is explicit. Mismatched schemes are one of the most common causes of large, systematic deviations in verification.For explicit runs, the verifier should record the initial time step, the total simulated time, and whether mass scaling or subcycling changed the effective step. A reproducible check is to extract the step size history and confirm the ratio of simulated time to wall-clock time is consistent with the reported cycle count. If an AI-generated deck claims a 10 ms simulation but the d3hsp shows only 4,000 cycles at 0.4 µs, the simulated time is actually 1.6 ms — a data-integrity error, not a physics difference.
Contact Algorithms
Contact in LS-DYNA is defined by a penalty or Lagrange multiplier formulation applied to a detected set of slave and master segments. The penalty method adds a stiffness proportional to penetration, controlled by SFS, SFM, and the contact stiffness scale factor; the Lagrange method enforces zero penetration through additional equations but can be more expensive and less robust for large sliding. The verifier must check three things: the contact type, the segment orientation, and the search tolerance.
Common types include *CONTACT_AUTOMATIC_SINGLE_SURFACE (self-contact within one part set), *CONTACT_AUTOMATIC_SURFACE_TO_SURFACE (two deformable bodies), and *CONTACT_AUTOMATIC_NODES_TO_SURFACE (rigid tool against a deformable workpiece). For a sheet-metal forming dataset, the punch and die are typically rigid and the blank is deformable, so a nodes-to-surface or surface-to-surface contact with the rigid tool as master is standard. Reversing master and slave changes the penalty stiffness distribution and can shift the predicted springback by a measurable amount.
Penetration depth is the primary observable. LS-DYNA reports maximum penetration in the glstat file and per-contact energy in sleout. A well-tuned penalty contact keeps maximum penetration below roughly 10% of the element thickness; persistent penetration above that threshold usually indicates an under-scaled penalty stiffness or a too-coarse slave surface. The verifier should also confirm that contact energy is a small fraction of internal energy — a sudden spike in contact energy often signals a missed contact or an inverted segment.
*CONTACT_AUTOMATIC_SURFACE_TO_SURFACE
$ SSID MSID SSTYP MSTYP SBOXID MBOXID SPR MPR
2 1 0 0 0 0 0 0
$ FS FD DC VC VDC PENCHK BT DT
0.1 0.1 0.0 0.0 0.0 0 0.0 1e20
$ SFS SFM SST MST SFST SFMT FSF VSF
1.0 1.0 0.0 0.0 1.0 1.0 1.0 1.0
In this example, SSID=2 is the slave (blank) and MSID=1 the master (tool), with friction coefficients FS=FD=0.1. The verifier should confirm that the part IDs match the intended geometry and that PENCHK is enabled when thin shells are involved, since penetration checking catches inverted slave segments that would otherwise pass silently.
Material Models Relevant to Dataset Generation
Material model choice determines the constitutive response and the set of parameters the AI must reproduce. Three families dominate verification datasets: metals plasticity, foams, and hyperelastic or viscoelastic materials.
For metals, *MAT_PLASTIC_KINEMATIC (MAT_003) is common for crash and forming. It requires density RO, Young's modulus E, Poisson's ratio PR, yield stress SIGY, tangent modulus ETAN, and a hardening parameter BETA that blends isotropic (BETA=1) and kinematic (BETA=0) hardening. A verifier checking a generated deck should confirm that ETAN is consistent with the true stress–strain curve beyond yield; a common AI error is to copy the elastic slope into ETAN, which produces unrealistically stiff plastic flow.
For foams, *MAT_CRUSHABLE_FOAM (MAT_063) uses a tabulated yield stress versus volumetric strain curve and a tensile cutoff. The verifier must check that the curve is monotonically increasing in compression and that the tensile cutoff is set, otherwise the foam will carry tension indefinitely. For rubber-like parts, *MAT_HYPERELASTIC_RUBBER (MAT_077) with a Mooney–Rivlin or Ogden formulation requires calibrated constants; a generated deck that supplies only C10 and C01 without D1 is nearly incompressible by default, which is usually intended but should be stated.
| Model | Key parameters | Typical verification check |
|---|---|---|
| MAT_003 Plastic Kinematic | RO, E, PR, SIGY, ETAN, BETA | ETAN from hardening curve; BETA matches loading mode |
| MAT_063 Crushable Foam | RO, E, PR, LCID (yield curve), TENSILE cutoff | Monotonic compression curve; cutoff present |
| MAT_077 Hyperelastic | RO, PR, C10, C01, D1 | D1 set for compressibility; constants calibrated |
The figure below summarizes how these three solver pillars interact in a verification workflow, from deck inspection through observable outputs to the pass/fail decision.
Putting the Pillars Together in a Verification Run
A reproducible verification pass proceeds as follows. First, parse the generated deck and extract the integration controls, contact definitions, and material cards. Second, run the deck with a fixed LS-DYNA version and record the d3hsp, glstat, and sleout outputs. Third, compare the observable quantities — simulated time from cycle count, maximum penetration, contact energy fraction, and key material state variables — against the reference. Fourth, classify each deviation as either a modeling-choice difference (e.g., penalty vs. Lagrange contact) or a data error (e.g., wrong ETAN, missing tensile cutoff).
A typical failure symptom illustrates the method. Suppose the generated deck reports a peak contact force 30% higher than the reference. Inspecting glstat shows maximum penetration is only 2% of element thickness, so the penalty stiffness is adequate. Inspecting the material card reveals ETAN set equal to E, making the blank effectively elastic. The deviation is therefore a material-parameter error, not a contact error, and the fix is to replace ETAN with the tangent modulus from the hardening curve. This diagnostic sequence — integration, then contact, then material — mirrors the order in which the solver pillars influence the result and gives the verifier a defensible basis for accepting or rejecting AI-generated training data.