1. Classify LS-DYNA Termination Messages by Root Cause

Why Termination Messages Are Evidence, Not Verdicts

LS-DYNA rarely prints a single sentence that names the true root cause. What it prints is the last thing it was doing when it stopped: a negative volume in a solid element, a mass-scaling warning that escalated, a license checkout failure, or a memory allocation that returned null. The same message text can appear under different root causes, and different messages can share one root cause. Classification therefore has to combine the literal message string with the surrounding context — the phase of the run, the last successful cycle, the model size, the machine state, and the messages immediately preceding the fatal one.

This case builds a repeatable triage procedure: capture the message set, normalize it, map it to a root-cause category, and record the evidence that justifies the mapping. The output is a classification table you can reuse on any failed run.

The Five Root-Cause Categories

For explicit and implicit LS-DYNA runs, most terminations fall into five practical buckets. The boundaries matter because the recovery action differs sharply between them.

CategoryTypical message signaturesContext that confirms itFirst recovery action
Input / model error*** Error reading input, negative volume in solid element #, node # used in element # is not defined, duplicate node id, invalid *MAT cardFails within the first few cycles, or during initialization before cycle 0; element/node IDs point to a specific regionFix the deck: mesh quality, connectivity, material card fields
Numerical instabilitynegative volume after many cycles, element failed cascade, out-of-range velocity, NaN in results, time step has become too smallRuns for hundreds or thousands of cycles, then diverges; energy grows without bound; one element distorts firstHourglass control, mesh refinement, contact/penalty tuning, time-step control
Resource exhaustionmemory allocation failed, out of memory, cannot allocate, OS-level Killed, disk quota exceededFails at a predictable model size or after a restart; d3hsp shows memory request near machine limitIncrease memory (memory=), reduce model, enable MPP decomposition
License issuelicense checkout failed, no license available, LS-DYNA license server not respondingFails immediately at startup, before any cycle; other jobs on the same host succeedCheck license server, release stale tokens, verify LSTC_FILE/server env
Environment / infrastructurewall-clock kill, node failure in MPP, filesystem error, segmentation faultFails at arbitrary cycle counts; correlates with cluster events, not model contentRe-run on healthy node, check scheduler logs, verify scratch space

Reading the Message Set in Order

The fatal line is the last line, but the diagnosis usually lives in the lines above it. A practical reading order:

  1. Locate the fatal line. Search the messag / d3hsp / stdout for *** Error, termination, or the last timestamped line.
  2. Find the last successful cycle and time. In d3hsp, the cycle/time table shows where the run stopped. A stop at cycle 0–5 points to input; a stop at cycle 50,000 points to instability or resources.
  3. Scan the preceding 20–50 lines. Warnings about negative volume, small time step, or mass scaling that appear just before the fatal line are the real signal.
  4. Cross-check the model size against the machine. If the model is large and the message is allocation-related, resource exhaustion is the leading hypothesis.
  5. Check whether the run ever started. No cycle output at all plus a license message means license; no cycle output plus an input error means deck.
Termination Message Triage — Root-Cause Decision Path Capture fatal line + last 50 lines Any cycle output before failure? No License text present? Yes LIC ISSUE No INPUT / MODEL ERROR deck, connectivity, material card Yes Allocation / memory message present? Yes RESOURCE EXHAUSTION memory=, MPP, scratch No Negative volume / tiny time step? Yes NUMERICAL INSTABILITY hourglass, mesh, contact No ENVIRONMENT / INFRASTRUCTURE

Worked Classification Example

Consider a run whose messag file ends with the following excerpt (illustrative, reconstructed from a typical solid-compression model):

   cycle       time      dt
   48210   3.2140E-03  1.02E-09
 *** Warning 40123: negative volume in solid element # 88214
 *** Warning 40123: negative volume in solid element # 88215
 *** Error 40123: negative volume in solid element # 88214
 termination

Applying the decision path: cycle output exists (48,210 cycles), so it is not a license or startup failure. No allocation message appears, so resource exhaustion is not the leading hypothesis. The fatal line is a negative volume, and it is preceded by warnings on the same element IDs. The run survived 48,210 cycles before failing, which rules out a pure deck error (those fail at cycle 0–5). The classification is numerical instability, with the evidence being the late-cycle timing, the repeated element IDs, and the absence of allocation or license text. The recovery direction is mesh quality and hourglass control in the region of elements 88214–88215, not a deck syntax fix.

Now contrast a second excerpt:

 LS-DYNA terminated
 *** Error: memory allocation failed for 2147483648 bytes
 requested by: solid element storage

No cycle table is present, the message names an allocation size, and the requested block is large. Classification: resource exhaustion. The recovery action is to raise the memory= value or reduce the model, not to touch the mesh.

Classification Record Template

Keep one row per failed run so the evidence is auditable and comparable across a batch of failures.

FieldWhat to recordExample
Run IDJob name / scheduler IDcrash_v3_mp4
Fatal lineExact text of the terminating message*** Error 40123: negative volume in solid element # 88214
Last cycle / timeFrom d3hsp cycle table48210 / 3.214E-03
Preceding warningsUp to 5 lines before fatalnegative volume #88214, #88215
CategoryOne of the five bucketsNumerical instability
JustificationWhich context signals drove the choiceLate cycle, repeated element IDs, no allocation text
Next actionTargeted recovery stepRefine mesh near elements 88214–88215; enable hourglass control
When two categories seem plausible, prefer the one whose recovery action is cheaper to test first. A quick re-run with a larger memory= value settles a resource-vs-instability ambiguity in minutes; a full remesh does not.
Do not classify from the fatal line alone. The same negative volume text appears in both input-error and instability cases; only the cycle count and the preceding warnings separate them. Recording the last successful cycle is the single most useful discriminator.

Verification of the Classification

A classification is only useful if it predicts the outcome of the recovery action. After applying the targeted fix, re-run and check: if the run now passes the previous failure cycle and the fatal message no longer appears, the classification was consistent with the cause. If the same message returns at a similar cycle, the category was likely wrong — for example, a resource problem misread as instability will reappear once memory pressure returns. Treat the classification table as a hypothesis log, not a final verdict, and update the category when the re-run contradicts it.

← Previous 📖 Contents Next →