Parity Status

The OpenRadioss corpus is tracked at fixture level. CI writes two reports:

• openradioss_parity_corpus_report.toml for machine-readable status;

• openradioss_parity_corpus_report.md for review and operator handoff.

Current Corpus Shape

The committed corpus has five tiers:

Tier	Purpose
geometry	Starter model state without engine execution.
geometry_meshing	Mesh topology and neutral model parity.
geometry_meshing_results	Starter and engine outputs reduced to native results.
geometry_meshing_results_post	Native post-processing replay from results.
verification_manual	Quarantined public end-to-end examples.

Status Semantics

blocked

The fixture does not yet have result artifacts to compare.

pending

The fixture has native reference results, but no solver parity pass has been recorded in the latest dynamic scoreboard.

pass / fail

The latest dynamic parity scoreboard contains a solved candidate and field comparison status for the fixture.

Field Policy

Dynamic result reports split fields into explicit parity scopes:

phase1_target

Solver/model-owned fields that count toward the first OpenRadioss parity gate: frame time and cycle, mesh identity, nodal U/V/A, transient RF, and TIME_STEP.

deferred

Fields that remain visible in the report but do not define the first solver parity gate yet: element recovery, plasticity, damage, contact, energy, and generic history channels.

The TOML report keeps both status for the full artifact and phase1_status for the current solver-owned gate. This prevents deferred OpenRadioss/post-processing work from hiding the active solver blockers.

Reference Provenance

Corpus reports include results_reference_kind for every fixture with results.npz. The committed clean-room fixtures currently report synthetic_clean_room_contract because their deterministic references are generated corpus contracts; real OpenRadioss replay output is built outside the fixture tree by CI and local runner commands. This makes the scorecard explicit about whether a failing row is comparing against a synthetic contract or against vendor-produced solver output.

Raw Output Ingestion

The native result path currently accepts numeric data from CSV exports, converted VTK animation files, status listings, and directly parsed binary T-family time-history frames. Binary A-family animation and H3D outputs are still metadata/classification coverage unless replay produces converted animation artifacts.

Readiness Diagnostics

Dynamic score artifacts also record whether a generated candidate was solved from a replayed deck that contains active loads and constraints. A readiness status such as missing_active_openradioss_loads_and_constraints means the reference has nonzero Phase 1 fields, but the replayed model currently gives the solver no equivalent load or boundary condition state. Those rows point to importer/deck-translation work before RF sign or U/V scaling can be judged.

Clean-room fixtures may carry their source load state in mapdl.dat while the generated OpenRadioss starter deck only covers geometry and material cards. The fixture reader applies those D/F/SF sidecar records only when the OpenRadioss replay has no active load state, so scheduled scorecards can separate solver-ready numeric failures from importer-readiness failures.

CI Cadence

The scheduled OpenRadioss parity workflow runs on a cron cadence and can also be started manually with workflow_dispatch. It uploads corpus and dynamic parity score artifacts so the next implementation batch can start from concrete failing fields rather than from anecdotal status.

Dynamic parity plans can use replay-produced reference results from an external root. When --reference-results-root is provided, each fixture row records whether comparison used external_reference_root or fell back to the committed fixture_contract. This keeps solver-vendor parity distinct from clean-room fixture contracts while preserving partial local runs.