4. Data acquisition and labeling

A crash FE model is only useful as machine-learning input once its geometry, connectivity, and quality metrics have been extracted into a solver-independent representation. LS-DYNA, Radioss, and Abaqus each store the same physical shell mesh in different keyword grammars, so the first engineering task is a deterministic parser that maps every deck into a common node/element table plus a per-element quality feature vector. This section covers deck extraction, defect annotation protocols, and the inter-annotator agreement statistics that decide whether a label set is trustworthy enough to train on.

4.1 Extracting meshes from heterogeneous decks

All three solvers describe shell meshes with nodes and connectivity, but the keyword blocks differ. LS-DYNA uses *NODE and *ELEMENT_SHELL; Radioss uses /NODE and /SHELL; Abaqus uses *NODE and *ELEMENT with a TYPE=S3/S4/S4R qualifier. A robust extractor should normalize to a single schema before any quality computation:

# normalized element record (one row per shell element)
elem_id, part_id, node_ids[3..4], thickness,
aspect_ratio, min_angle_deg, max_angle_deg,
jacobian_min, warp_deg, skew_deg, taper_ratio,
free_edge_flag, duplicate_node_flag, normal_flip_flag

For LS-DYNA, read the deck in fixed-width mode because node coordinates are column-aligned; free-format parsing silently corrupts negative coordinates. For Radioss, strip the leading # comment lines and honor the /SHELL card's node ordering, which follows the same right-hand rule as LS-DYNA. For Abaqus, expand element sets and resolve *ELSET references so that part-level labels survive extraction. A practical check is to compare total element count and bounding-box extents against the solver's own summary output; a mismatch above 0.1% usually indicates a missed continuation line or an unexpanded set.

Keep the raw deck hash (SHA-256 of the input file) alongside every extracted mesh. When a label is later disputed, the hash lets you prove which deck revision produced the geometry.

4.2 Quality metrics that define a defect

Mesh defects in crash models are not binary; they are threshold crossings on continuous quality metrics. The annotation protocol must therefore fix both the metric definitions and the thresholds. The following table gives a defensible starting set, expressed in the same sign and angle conventions used by LS-DYNA's *CONTROL_CHECK_SHELL output so that automated checks and human labels agree.

MetricDefinitionTypical warningTypical error
Aspect ratioLongest edge / shortest edge> 5.0> 10.0
Min interior angleSmallest angle in the element plane< 30°< 15°
Max interior angleLargest angle in the element plane> 150°> 165°
JacobianMinimum determinant of the isoparametric map< 0.6< 0.3
WarpageOut-of-plane deviation of a quad> 15°> 30°
SkewDeviation from 90° between mid-lines> 45°> 60°
Free edgeEdge not shared by two shells—any unintended
Duplicate nodeCoincident nodes within tolerance—any

Thresholds are model-class dependent. A full-vehicle frontal model may tolerate aspect ratios up to 8 in non-critical regions, while a pedestrian head-impact submodel should stay below 4. The protocol must record the threshold set as metadata, not bury it in code, so that labels remain interpretable when the dataset is reused.

4.3 Annotation protocol

Annotation is performed per element, not per part, because a single part often contains both clean and defective regions. The protocol below is designed to be executable by a trained CAE engineer in a viewer such as LS-PrePost, Animator, or a custom PyVista tool.

  1. Load and verify. Open the normalized mesh, confirm element count and bounding box against the extraction report, and enable the quality contour for the metric under review.
  2. Apply the threshold set. Color elements by the warning and error thresholds. This produces a candidate set, not the final label.
  3. Adjudicate context. For each candidate, decide whether the defect is real (would degrade crash response or cause solver instability) or acceptable (in a rigid, non-deforming, or low-strain region). Record the reason code.
  4. Assign the label. Use a three-class scheme: 0 = clean, 1 = minor defect, 2 = critical defect. Critical means the element is expected to cause negative volume, hourglassing, or non-physical stress concentrations.
  5. Record provenance. Store annotator ID, timestamp, deck hash, threshold set ID, and reason code with every label.
Do not let the threshold contour become the label. Thresholds generate candidates; the annotator's contextual judgment produces the ground truth. Skipping step 3 inflates the critical-defect rate and teaches the model to reproduce the threshold, not the engineering decision.

4.4 Inter-annotator agreement for mesh quality

Because labels are ordinal and imbalanced, Cohen's kappa on the raw three-class labels is necessary but not sufficient. Report three statistics: percentage agreement, Cohen's weighted kappa (linear weights), and per-class F1 between annotators. A weighted kappa below 0.60 on the critical class means the protocol is ambiguous and must be revised before training.

Disagreements cluster in predictable places: warped quads near trimmed holes, transition regions between coarse and fine mesh, and elements adjacent to rigid bodies. A useful calibration exercise is to have two annotators label the same 200-element sample, compute the statistics, then jointly review every element where they differed. The review outcome is a protocol amendment, for example a rule that warpage below 20° in a rigid region is always 0.

Deck Extraction → Annotation → Agreement Pipeline Solver Decks LS-DYNA .k Radioss .rad Abaqus .inp SHA-256 hash fixed-width parse Normalized Mesh nodes + connectivity part_id mapping quality features count / bbox check ±0.1% tolerance Threshold Candidates aspect > 5 / 10 angle < 30° / 15° jacobian < 0.6 / 0.3 warning / error threshold set ID Annotation 0 clean 1 minor 2 critical reason code annotator ID Inter-Annotator Agreement Gate 200-element calibration sample weighted κ per-class F1 % agreement κ < 0.60 ? revise protocol re-review diffs Disagreement hotspots: warped quads near trimmed holes · coarse/fine transitions · rigid-body adjacency Outcome: protocol amendment → re-annotate → freeze dataset with deck hash + threshold set ID

4.5 A minimal annotation record

The following JSON fragment shows the fields that must accompany each labeled element. It is deliberately small so that it can be emitted by any viewer plugin and merged into a dataset without schema negotiation.

{
  "deck_hash": "9f2c...a41d",
  "solver": "lsdyna",
  "elem_id": 104872,
  "part_id": 37,
  "metrics": {"aspect": 7.4, "min_angle": 22.1, "jacobian": 0.41, "warp": 18.6},
  "threshold_set": "full_vehicle_v3",
  "label": 2,
  "reason": "negative_jacobian_risk",
  "annotator": "eng_04",
  "timestamp": "2025-03-11T09:42:17Z"
}

With this record structure, the dataset is reproducible: given the deck hash and threshold set ID, any engineer can regenerate the candidate set and audit the labels. The agreement statistics then tell you whether the labels encode a consistent engineering judgment or merely the noise of an under-specified protocol.