1. PRIMER Model Check Baseline: Open, Inspect, and Export a Clean Model Summary

Why a Baseline Comes First

Before any batch automation can be trusted, you need a reference point that describes the model as it actually is. In Oasys PRIMER, that reference point is a model check baseline: a single, repeatable run of the standard check suite against a known model file, with the findings captured in a structured form you can diff against later. Without it, every subsequent scripted run produces numbers with nothing to compare them to, and regressions hide inside noise.

This case establishes that baseline for one model. The task is deliberately narrow: open an existing PRIMER model, run the standard model check suite, and export a structured summary covering element quality, connectivity, and free-edge findings. The output is a file you can archive, version, and later compare against automated runs.

What the Standard Check Suite Covers

PRIMER's model checking groups findings into families. For a baseline you want at least three of them captured explicitly, because they answer different questions:

• Element quality — shape and distortion metrics per element (aspect ratio, warping, Jacobian, skew, taper). These tell you whether the mesh is numerically usable, independent of how it is connected.
• Connectivity — duplicate elements, coincident nodes, unmerged nodes, elements referencing missing nodes, and orphan nodes. These tell you whether the topology is internally consistent.
• Free edges — edges belonging to exactly one shell element. In a closed shell model, free edges should appear only at intentional boundaries; unexpected free edges usually indicate a hole, a missing element, or a mismatched node.

Each family produces counts and, critically, identifiers — element IDs, node IDs, or edge node pairs. The baseline is only useful if those identifiers are preserved, because a count alone cannot tell you which element changed between runs.

The Baseline Workflow

The workflow below is the manual, inspectable version. It is intentionally done by hand once so that you understand every field before you automate it in later cases.

1. Open the model. Load the target file in PRIMER and confirm the model tree shows the expected parts, properties, and element count. Record the element and node totals — these become header values in the summary.
2. Run the check suite. Invoke the model check function across the three families. Let the run complete; do not dismiss dialogs before noting which checks were enabled, since the baseline is only comparable if the same checks are active next time.
3. Inspect before exporting. Open each findings list and confirm the entries are real. A baseline that faithfully records a false positive is worse than no baseline, because it trains you to ignore the check.
4. Export the structured summary. Write the findings to a delimited file with one row per finding, carrying the check family, the identifier, and the metric or condition that triggered it.
5. Verify the export. Re-open the exported file and confirm the row counts match the on-screen counts for each family.

Building the Structured Summary

The summary is a delimited text file, not a screenshot and not a PDF. A flat table with a fixed column set is what makes later diffing possible. Use this schema:

Two header lines precede the data: a comment line recording the model file name, revision, element count, node count, and the exact set of checks enabled; and the column header row. Everything after that is one row per finding. Keeping the check set in the header is what makes two baselines comparable — a run with fewer checks enabled will show fewer findings for reasons that have nothing to do with the model.

Reading the Baseline

A baseline is not a pass/fail verdict; it is a description. The useful judgement comes from three questions applied to the exported rows:

• Are the quality findings clustered? A handful of low-Jacobian elements in a transition region is normal. A large contiguous cluster usually points to a meshing setup problem rather than isolated bad elements.
• Do connectivity findings pair up? Duplicate elements normally appear in pairs; a duplicate with no partner suggests a partially deleted element. Orphan nodes often sit near free edges, because a deleted element leaves its nodes behind.
• Are free edges where you expect them? Compare the free-edge node pairs against the intended model boundary. Free edges in the interior of a closed shell are the highest-value finding in the whole baseline, because they almost always indicate a real defect.

Verification and Failure Symptoms

Confirm the baseline is trustworthy before archiving it:

• Row counts per family in the CSV match the on-screen counts in PRIMER.
• Every entity_id resolves to a real element or node when queried in PRIMER.
• The header records the same element and node totals shown in the model tree.
• Re-running the check suite without changing the model produces an identical file (apart from any timestamp line).

If the export is not reproducible, the usual causes are: a check left disabled between runs, a model that was edited and not re-saved, or an export that silently truncated at a row limit. If identifiers are missing or replaced by sequential row numbers, the export is not a baseline — it cannot be diffed, and it should be regenerated with ID output enabled.

Baseline Record

The following record is the deliverable for this case. Fill it in for the model you are baselining and archive it with the CSV.

With this record and its CSV archived, the model has a defined starting state. Later automated runs can be compared against it row by row, and any change in element quality, connectivity, or free-edge topology becomes visible as a concrete difference in identifiers rather than a vague shift in a count.