VV: Group Microtexture Regions full V&V

[imikejackson]

Closes the outstanding gate items left open by the initial V&V cycle (#1637) and promotes the report from DRAFT to READY FOR REVIEW.

No SIMPLNX algorithm source changed in this PR. The only non-documentation edit is a corrected comment in one test fixture.

What changed

Item	Before	After
Status	DRAFT	READY FOR REVIEW
Legacy comparison	"Not run" (blamed the RNG seed)	N/A — no public legacy equivalent
Code path coverage	"9 of 9 exercised" (contradicted the table)	7 of 9, in both the dashboard row and the section
D2 / D3 affected users	overstated 6.5.171 migration impact	corrected
OOC verification	listed as outstanding	out of scope for this round, recorded as a decision

The substantive finding

GroupMicroTextureRegions ships in DREAM3D 6.5.171 as a private filter — listed in _PrivateFilters in Source/Plugins/Reconstruction/ReconstructionFilters/SourceList.cmake and registered via ADD_SIMPL_FILTER(... FALSE ...), which the legacy source documents as "available from other filters but the user will not be able to use them from the DREAM3D user interface."

It is therefore compiled but not instantiable from a pipeline, so an A/B against 6.5.171 is not merely impractical — it is impossible. That is a stronger and more accurate justification than the non-reproducible-RNG argument the report previously gave.

This propagated: D2 and D3 both claimed migration impact on 6.5.171 users who could never have run the filter. Both corrected. D3 now also explains why a bug introduced in 2014 survived to discovery — it lived in a filter nobody could reach.

Deliverables disagreed with each other

On the UseRunningAverage=false comparison target, the provenance sidecar was correct; the report described it incorrectly and the test comment contradicted itself mid-sentence.

Verified against the source: execute() iterates for(j = 0; j < groupList.size(); j++) over a list that grows as neighbors are accepted, passing groupList[j] to determineGrouping() as referenceFeature. The local is named firstFeature but is the current BFS frontier feature, not the seed. Grouping is therefore the transitive closure of the pairwise-tolerance relation along neighbor chains. Report and test comment now match the sidecar.

The Tolerance Boundary fixture was additionally re-derived under all three possible seed orders (getSeed() draws randomly among unparented features); F1, F2, and F3 each yield the partition {F1,F2}, {F3}, so the assertion is seed-order independent.

What a reviewer is actually being asked

One question, and it is about intent, not mechanics:

Grouping is the transitive closure of the tolerance relation. At 10° tolerance, features at Φ = 0°, 8°, 16° all merge into a single group even though the end members are 16° apart. This matches legacy GroupFeatures::execute — but is it the intended user-facing semantic, or an inherited accident?

A secondary item is whether the invariant list in RandomizeParentIds invariants is exhaustive.

This is a domain/intent judgement about microtexture-region grouping, not a deep code review. Both items are recorded in vv/provenance/GroupMicroTextureRegionsFilter.md under Second-engineer oracle review.

Out of scope

OOC verification. Not required by the MTR SBIR deliverable and owned separately by another engineer. Recorded in the report as a deliberate exclusion rather than an open gap. Closing it would require a ForceOutOfCore sentinel fixture plus an OOC build configuration.

Verification

Full rebuild of preset NX-Com-Qt69-Vtk96-Rel, then ctest -R GroupMicroTexture → 5/5 passed, 0 failed (2026-08-10). This supersedes the report's previous 2026-06-11 claim, which predated several merges into develop. clang-format made no changes to the edited test file.

Per vv_policy.md, promotion to COMPLETE and the Sign-off field are filled at merge by the approving reviewer.

🤖 Generated with Claude Code