2. Crash CAE model anatomy

A crash CAE model is not a single monolithic artifact. It is a layered assembly of geometry, mesh topology, material definitions, connections, boundary conditions, and solver control data. Understanding this anatomy is a prerequisite for automated checking: every quality rule you will later encode targets a specific component or data structure. This section dissects the model into its constituent parts and maps them to the file formats used by LS-DYNA, PAM-CRASH, and Radioss.

1. The Six Structural Layers of a Crash Model

Regardless of solver, a crash model can be decomposed into six layers. Each layer has its own data structures, its own failure modes, and its own checking priorities.

The critical insight is that these layers are interdependent. A missing material ID on a shell element will cause the solver to either abort or assign a default material, which then produces meaningless deformation. An automated checker must therefore validate not only each layer independently but also the cross-references between layers.

2. File Formats Across Solvers

Each solver ecosystem uses a distinct input format, but the underlying data structures are remarkably similar. The table below maps the equivalent constructs.

In LS-DYNA, the keyword file is organized as a sequence of keyword blocks, each beginning with * and terminated by the next keyword or EOF. PAM-CRASH uses a slash-prefixed command structure with a more rigid column format. Radioss separates the starter input (model definition) from the engine input (runtime control), which is an important distinction for automated checking: the starter file contains the model anatomy, while the engine file contains the simulation control.

3. Data Structures Inside the Solver

When a solver reads an input deck, it builds internal arrays. Understanding these arrays helps you design checks that operate on the same abstractions.

• Node array: indexed by node ID, storing (x, y, z) coordinates. In LS-DYNA, node IDs need not be contiguous; the solver builds a hash map from ID to internal index.
• Element connectivity: for shells, four node IDs per element; for solids, eight. The connectivity table is the primary target for free-edge and duplicate-element checks.
• Part table: maps part IDs to material IDs and section IDs. A part is the fundamental grouping unit in LS-DYNA; in Radioss, the equivalent is the /PART card linking /MAT and /PROP.
• Set definitions: node sets, element sets, and segment sets. These are used by contact definitions, boundary conditions, and output requests. Missing or empty sets are a common source of silent errors.
• Contact segment list: derived from element faces. The solver generates segments from shell elements or solid faces, and the contact algorithm operates on these segments.

4. A Minimal LS-DYNA Example

Consider a simplified frontal impact model with a single shell part. The following excerpt shows the essential keyword blocks and their relationships.

*NODE
       101,     0.000,     0.000,     0.000
       102,   100.000,     0.000,     0.000
       103,   100.000,    50.000,     0.000
       104,     0.000,    50.000,     0.000
*ELEMENT_SHELL
         1,       1,     101,     102,     103,     104
*PART
         1,       1,       1
*SECTION_SHELL
         1,         2,       1.0,       5,       0.0,       0.0
*MAT_PIECEWISE_LINEAR_PLASTICITY
         1,   7.85e-9,  210000.0,       0.3,     0.0,     0.0
*CONTACT_AUTOMATIC_SINGLE_SURFACE
         1,       1,       1,       1,       1,       1
*INITIAL_VELOCITY
         1,       1,   -15000.0,       0.0,       0.0
*CONTROL_TERMINATION
       0.050
*DATABASE_BINARY_D3PLOT
       0.001

In this example, the part card (*PART) links part ID 1 to section ID 1 and material ID 1. The section card defines a shell thickness of 1.0 mm with five integration points through the thickness. The material card uses a piecewise linear plasticity model with density 7.85e-9 (tonne/mm³), Young's modulus 210000 MPa, and Poisson's ratio 0.3. The initial velocity card applies -15000 mm/s in the X direction to the node set. The termination card sets the end time to 0.050 s, and the database card requests D3PLOT output every 0.001 s.

An automated checker would verify, among other things: that nodes 101–104 exist, that element 1 references valid nodes, that part 1 references valid section and material IDs, that the thickness is positive, that the density is in the correct unit system, and that the initial velocity direction is consistent with the intended impact direction.

5. Common File Format Pitfalls

• Unit system inconsistency: LS-DYNA does not enforce units. A model using mm-tonne-s must use density in tonne/mm³ and stress in MPa. Mixing units is a frequent source of erroneous results.
• Column-sensitive formats: PAM-CRASH and Radioss use fixed-column formats in some cards. A misplaced decimal point or missing field can shift data into the wrong column.
• Include file resolution: LS-DYNA uses *INCLUDE to reference external files. Automated checkers must resolve include paths relative to the main deck, not the current working directory.
• ID collisions: Node IDs, element IDs, part IDs, and material IDs occupy separate namespaces in LS-DYNA but can collide in some preprocessors. A checker should validate uniqueness within each namespace.
• Empty sets: A set defined but containing zero entities will cause contact or boundary condition cards to silently do nothing.

6. Visualizing the Model Anatomy

The following diagram shows the layered structure of a crash CAE model and the cross-references that automated checks must validate. Each layer is represented as a block, and the arrows indicate mandatory references.

The diagram emphasizes that connections, contact, and boundary conditions all reference node or element sets, which in turn reference the underlying mesh. A missing or empty set breaks the chain and causes silent failures. Automated checking must therefore validate set membership as rigorously as it validates direct ID references.

7. Practical Checklist for Model Anatomy Validation

The following checklist summarizes the minimum validation steps for each layer. It is intended as a starting point for building an automated checker, not as an exhaustive specification.

Each check maps to a specific data structure and a specific failure mode. By organizing your automated checker around these layers, you ensure that every rule has a clear target and a clear diagnostic message. The next section will build on this anatomy to define the quality metrics and rule engine that operate on these structures.