2. Graph representation of finite element crash models

Converting a finite element (FE) crash model into a graph is the single most consequential design decision in a GNN-based surrogate pipeline. The graph is not a neutral container: the choice of node, edge, and feature set determines what the network can physically learn, how large the model becomes, and whether predictions remain stable under mesh refinement. This section establishes the mapping conventions used throughout the course and shows how to build them for shell, solid, and spot-weld components.

Two Node Conventions: Integration Points vs. Mesh Nodes

An LS-DYNA or Radioss crash deck contains two natural candidate node sets. Mesh nodes are the geometric vertices stored in the *NODE block, each with coordinates and six degrees of freedom. Integration points are the quadrature locations inside each element where stresses and strains are actually evaluated — for example, through-thickness points in a shell, or Gauss points in a hexahedral solid.

The distinction matters because crash-relevant quantities live in different places. Nodal displacement, velocity, and acceleration are defined at mesh nodes. Plastic strain, stress tensor components, and damage variables are defined at integration points. If the learning target is a field like equivalent plastic strain (PEEQ), integration-point nodes give a direct one-to-one correspondence between graph node and label. If the target is nodal displacement or a global intrusion curve, mesh nodes are the natural choice.

A practical compromise used in many published crash GNNs is the element-centered graph: one node per element, positioned at its centroid, carrying averaged integration-point features. This keeps the graph small (roughly one node per element rather than per node) and makes element deletion — a defining feature of crash simulation — directly representable as node removal. The trade-off is loss of through-thickness resolution, which is acceptable for panel-level response but not for predicting delamination or local necking.

Edges from Element Connectivity

Edges encode which degrees of freedom interact. The most direct construction reads the connectivity blocks — *ELEMENT_SHELL, *ELEMENT_SOLID, *CONSTRAINED_SPOTWELD — and inserts an edge for every pair of nodes (or elements) sharing an element. For a shell quad with nodes n1..n4, this yields four boundary edges plus two diagonals if a fully connected clique is used, or four edges if only the element boundary is retained.

Three edge topologies are common:

• Clique (fully connected per element): every node in an element connects to every other. Simple to build, but a hexahedral solid produces 28 edges per element, inflating memory quickly.
• Boundary-only: connect only adjacent nodes along element edges. Sparse and geometrically faithful, but a shell quad becomes a 4-cycle with no diagonal, which weakens information flow across the element.
• Star / dual: introduce an element node and connect it to its constituent mesh nodes. This is the element-centered graph in bipartite form and is the most common choice for heterogeneous models.

Edge features should carry the mechanical meaning of the connection. Useful attributes include the shared element type, the edge length, the relative orientation of the connected elements' normals, and — for shells — whether the edge crosses a fold line or lies in a flat region. These features let the network distinguish membrane-dominated from bending-dominated load paths without being told explicitly.

Feature Engineering by Component Type

Crash models are heterogeneous: stamped steel and aluminum shells, cast or extruded solids, and spot welds joining them. Each component type exposes different physics, so node features should be assembled per component class.

For shells, thickness and integration-point count are essential because they control bending stiffness and through-thickness strain gradient. A common mistake is to feed only nodal coordinates; the network then cannot distinguish a 0.8 mm door outer from a 2.0 mm B-pillar reinforcement at the same location. For solids, element volume and characteristic length act as a mesh-density signal that helps the model generalize across refinement levels. For spot welds, the weld diameter and stack thickness determine the nugget's shear and peel capacity, so they must be present as node features on the weld node.

Material features deserve care. Raw material IDs are categorical and should be embedded, not treated as ordinal. More useful is a small vector of physical parameters — density, Young's modulus, initial yield, hardening exponent — extracted from the *MAT card. This lets the network interpolate to unseen materials rather than memorizing IDs.

Building the Graph: A Concrete Example

Consider a simplified B-pillar model with 12,000 shell elements, 400 solid elements in the rocker, and 180 spot welds. A reproducible construction in Python with PyTorch Geometric proceeds as follows.

import torch
from torch_geometric.data import Data

# nodes: one per element (element-centered graph)
# x shape [N, F], F = 9 features
# columns: [cx, cy, cz, thickness, mat_E, mat_yield, peeq, elem_type, volume]
x = torch.tensor(node_features, dtype=torch.float)

# edges from shared-node connectivity, boundary-only for shells
edge_index = torch.tensor(connectivity, dtype=torch.long)  # [2, E]
edge_attr  = torch.tensor(edge_features, dtype=torch.float) # [E, 4]

data = Data(x=x, edge_index=edge_index, edge_attr=edge_attr)
print(data)
# Data(x=[12580, 9], edge_index=[2, 41200], edge_attr=[41200, 4])

The expected output confirms node and edge counts. A useful sanity check is to verify that the number of connected components equals one for a fully welded body-in-white; if it exceeds one, a spot-weld connectivity block was likely missed. Another check is to confirm that no node has degree zero, which would indicate an orphaned element.

Normalization and Scale Consistency

Crash features span many orders of magnitude: coordinates in millimeters, stresses in megapascals, strains dimensionless. Without normalization, gradient descent is dominated by coordinate magnitude. Standard practice is to standardize each feature channel using statistics computed over the training set only, then apply the same transform at inference. For coordinates, subtract the model centroid and divide by the bounding-box diagonal so that all models share a comparable scale — this is essential when training on a fleet of vehicles of different sizes.

Direction conventions must be fixed before feature extraction. Throughout this course, the global coordinate system follows the vehicle convention: x forward, y left, z up, with the origin at the front bumper center on the ground plane. Shell normals follow the right-hand rule from the element node ordering in the input deck. Any transformation of these conventions must be stated explicitly, because a sign flip in the normal direction inverts the bending curvature feature and will silently corrupt training.

Practical Checks Before Training

Three verification steps catch most graph-construction errors. First, confirm that the graph is connected and that the number of edges scales linearly with the number of elements — a superlinear jump usually means a clique was built where boundary-only was intended. Second, inspect feature histograms per component type; a shell thickness channel that contains solid element values indicates a mislabeled element type. Third, run a single forward pass with a trivial GCN layer and confirm that output shape matches the label tensor. These checks take minutes and prevent days of debugging a model that was never given the right graph.

The graph built here becomes the fixed input to every subsequent stage: message passing, temporal rollout, and uncertainty estimation. Getting the node, edge, and feature conventions right at this stage is what makes the rest of the pipeline physically meaningful rather than a black-box fit to coordinates.