DEV Community

Cover image for Catch naming drift before an Abaqus run: a deterministic contract-audit pattern in Python
Mid-Mountain
Mid-Mountain

Posted on

Catch naming drift before an Abaqus run: a deterministic contract-audit pattern in Python

#python #opensource #testing #ai

Disclosure: I maintain the open-source repository described below. This article was prepared with AI assistance and reviewed before publication.

Automation failures in finite-element projects are often blamed on the solver, but many failures begin earlier. A script renames a region while a later load still points to the old name. An output request no longer covers the quantity needed by a review. A report calls a result "approved" even though the solver and physical-review gates are incomplete.

These are contract problems. They are useful to detect before launching a licensed application or handling a large model. In this tutorial I will use a small, dependency-free Python demo to show the pattern.

1. Run the tagged example 

git clone https://github.com/1348109517/abaqus-agent-skills.git
cd abaqus-agent-skills
git checkout v0.3.0
python scripts/run_demo.py --scenario complete
Enter fullscreen mode Exit fullscreen mode

The complete synthetic contract produces:

PASS: 8
WARNING: 0
REVIEW_REQUIRED: 0
Enter fullscreen mode Exit fullscreen mode

The command writes report.json and report.md. Both reports are derived from the same ordered finding objects. They contain an input SHA-256 digest but no runtime timestamp by default, so rerunning an unchanged contract yields deterministic review artifacts.

2. Introduce naming drift

Now run the committed failure case:

python scripts/run_demo.py --scenario naming-drift
Enter fullscreen mode Exit fullscreen mode

Its summary is:

PASS: 7
WARNING: 0
REVIEW_REQUIRED: 1
Enter fullscreen mode Exit fullscreen mode

The C-REF-001 finding points to loads.Gravity.region. The load refers to ExcavationFaceRenamed, while that region is not declared by the contract. The command still exits successfully because the auditor completed its job; the finding is a structured request for human review, not a Python crash.

This separation matters in CI. An invalid JSON shape or an I/O failure should fail the tool. A valid contract containing an engineering-review finding should produce a stable artifact that a person or later workflow can inspect.

3. Keep evidence states narrower than engineering claims 

python scripts/run_demo.py --scenario evidence-overreach
Enter fullscreen mode Exit fullscreen mode

This scenario also returns seven passes and one REVIEW_REQUIRED finding. C-EVIDENCE-001 records that an engineering claim was marked approved before the declared solver and physical-review gates were complete.

The key rule is intentionally conservative:

static contract review != solver evidence
solver completion       != physical correctness
physical review         != automatic claim approval
Enter fullscreen mode Exit fullscreen mode

A deterministic preflight can verify names and declared dependencies. It cannot choose a constitutive model, judge mesh adequacy for a specific claim, interpret an ODB, or certify an engineering conclusion.

4. Adapt the pattern safely

The public example uses synthetic data only. For another workflow, start with a small schema that names producers and consumers explicitly: parts, instances, regions, materials, steps, loads, output requests, and evidence gates. Keep machine-checkable references separate from decisions that require domain judgment. Prefer a status such as REVIEW_REQUIRED when automation has reached its evidence boundary.

Repository:
https://github.com/1348109517/abaqus-agent-skills

Verified v0.3.0 release:
https://github.com/1348109517/abaqus-agent-skills/releases/tag/v0.3.0

The project is early-stage, Apache-2.0 licensed, and independently maintained. It is not affiliated with or endorsed by Dassault Systemes or SIMULIA. It does not include Abaqus, official documentation, solver binaries, or private model data.

If the project is useful in your workflow, star the repository to follow its development. I would also appreciate a reproducible issue report or a proposal for another synthetic contract failure; those concrete cases are more useful at this stage than broad adoption claims.

Top comments (0)