4. Introduction to automated checking

Manual CAE model checking does not scale. A full-vehicle crash model may contain 3–8 million elements, tens of thousands of connections, hundreds of materials, and dozens of load cases. A reviewer who inspects such a deck by hand will inevitably miss things — a duplicated node, a rigid body with no mass, a contact pair referencing a deleted part. Automated checking replaces that unreliable human pass with deterministic, repeatable, and traceable verification. This chapter explains the two dominant technical strategies for automation, how they differ in what they can and cannot detect, and how to embed them into a real CAE workflow.

Why Automate, and What "Checking" Actually Means

In crash CAE, a "check" is any assertion about the model that can be evaluated to pass, fail, or warn. Checks fall into roughly four families:

• Topological / connectivity checks — free edges, duplicate elements, orphan nodes, unconnected rigid bodies, penetrations between parts.
• Numeric / consistency checks — negative or zero mass, missing section properties, unit-system mismatches, out-of-range thickness, inconsistent material IDs.
• Modeling-practice checks — solver keyword compliance, time-step control, hourglass control settings, contact friction definitions, output request coverage.
• Correlation-oriented checks — comparison against a validated baseline model, expected mass distribution, or previously approved deck revisions.

The first three families are largely expressible as explicit rules. The fourth is where data-driven methods become attractive.

Rule-Based Checking

A rule-based checker encodes engineering knowledge as explicit conditions. Each rule has a scope (which entities it applies to), a predicate (the condition), a severity, and a message. A typical rule in a crash model might read: every *CONSTRAINED_EXTRA_NODES set must reference at least one node that belongs to a defined part. If the predicate fails, the checker emits a finding with the offending entity IDs.

Rule-based checking is deterministic, explainable, and cheap. It runs in seconds to minutes on a full deck, produces identical results for identical input, and every finding can be traced back to a written rule — which matters enormously for audit and sign-off. Its weakness is coverage: it only catches what someone thought to write a rule for. Novel modeling errors, subtle geometry problems, and "this model looks wrong but no rule fires" situations slip through.

Implementation is usually straightforward. Most teams parse the solver deck into an intermediate representation (entity tables keyed by ID), then evaluate rules against that representation. A minimal rule definition in a Python-based checker might look like:

RULES = [
    {
        "id": "MAT-001",
        "scope": "material",
        "predicate": lambda m: m.density > 0,
        "severity": "error",
        "message": "Material {id} has non-positive density."
    },
    {
        "id": "CON-014",
        "scope": "contact",
        "predicate": lambda c: c.slave_set and c.master_set,
        "severity": "error",
        "message": "Contact {id} is missing a slave or master set."
    },
]

The predicate is the engineering content; the surrounding machinery is plumbing. Keeping rules data-driven (declared in a table or YAML) rather than hard-coded makes them reviewable by CAE engineers who are not programmers.

Data-Driven Checking

Data-driven checking learns what "normal" looks like from a corpus of previously accepted models, then flags deviations. The corpus might be 200 validated full-vehicle decks, or the historical revision history of a single program. Features are extracted per entity or per subsystem — element quality metrics, mass per part, connection counts, material property distributions, contact stiffness ranges — and a model is scored against the learned distribution.

Two practical formulations dominate:

• Statistical / outlier detection. For each feature, compute a robust baseline (median and MAD, or a percentile band) across the corpus. A new model whose part mass falls outside, say, the 1st–99th percentile band is flagged for review. This is simple, interpretable, and works with small corpora.
• Supervised classification. If historical models are labeled "accepted" or "rejected," a classifier can learn which feature combinations predict rejection. This catches multivariate patterns that univariate thresholds miss, but requires labeled data and careful validation to avoid overfitting.

Data-driven methods excel at the "no rule fires but something is off" case. They are also naturally adaptive: as the design evolves, the baseline can be refreshed. Their costs are real, though. They need a clean, consistent corpus — mixing unit systems or solver versions poisons the baseline. They produce findings that are statistical, not causal, so a flagged part may be a legitimate design change rather than an error. And they are harder to defend in a formal review: "the model is 3.2 standard deviations from the mean" is a weaker argument than "the model violates rule MAT-001."

Choosing and Combining

In practice the two approaches are complementary, not competing. A sensible architecture runs rule-based checks first as a fast gate, then applies data-driven checks to the survivors. The table below summarizes the trade-off.

Integration into the CAE Workflow

Automated checking only delivers value if it runs at the right moment and its results are acted upon. The most effective integration point is pre-solve, immediately after the deck is assembled and before the solver is launched. Running checks post-solve is too late — a bad model wastes hours of compute. Running them only at final sign-off is also too late — errors found then force expensive rework.

A practical pipeline has four stages:

1. Extract. Parse the assembled deck into entity tables. This is the only solver-specific step; everything downstream is solver-agnostic.
2. Rule pass. Evaluate all rules, collect findings with entity IDs and severities.
3. Data pass. Score the model against the baseline; emit anomaly findings.
4. Gate. If any error-severity finding exists, block the solve and notify the responsible engineer. Warnings are logged but do not block.

The gate is the critical design decision. A checker that only produces a report will be ignored under deadline pressure. A checker that blocks the solve forces resolution. Most teams adopt a tiered policy: errors block, warnings require acknowledgment, informational findings are logged only.

Worked Example: A Pre-Solve Gate

Consider a front-end subsystem deck with 420,000 elements. The checker runs in 38 seconds. It reports:

• 3 errors: two *CONSTRAINED_EXTRA_NODES sets referencing deleted nodes; one material with zero density.
• 11 warnings: five parts with thickness outside the 1st–99th percentile band of the baseline; six contact pairs with friction coefficients below the historical minimum.
• 1 informational: total mass 2.3% above the previous revision.

The errors block the solve. The engineer fixes the three entities, re-runs the checker (now 0 errors), and the solve proceeds. The warnings are reviewed and two are accepted as intentional design changes; the rest are corrected. The informational mass drift is noted for the correlation engineer. This is the loop that makes automation pay off: fast feedback, explicit decisions, and a traceable record.

Common Pitfalls

Three failure modes recur. First, rule rot — rules written for an old solver version or an obsolete modeling convention keep firing and get ignored, training engineers to dismiss the checker. Rules need owners and periodic review. Second, baseline contamination — if the corpus used for data-driven checks includes models that were later found defective, the baseline is wrong and anomalies are masked. Third, gate fatigue — if the gate blocks too often on low-value findings, engineers route around it. Severity calibration is not optional.

The diagram above shows the four-stage pipeline and the gate decision. The key insight is that rule-based and data-driven passes feed the same findings stream and the same gate — they are two detection mechanisms behind one policy. That separation lets you tune each independently: tighten rules without retraining the baseline, or refresh the baseline without touching the rule set.

What to Take Forward

Automated checking is not a replacement for engineering judgment; it is a filter that removes the mechanical errors so judgment can focus on the substantive ones. Rule-based checks give you determinism, explainability, and auditability. Data-driven checks give you coverage of the unexpected. Integrated pre-solve with a severity-calibrated gate, they turn model quality from a heroic manual effort into a repeatable process — which is the only way to keep crash CAE trustworthy at production scale.