BUG: ComputeFaceIPFColoring assigns wrong-phase symmetry operator on mixed-phase faces

[imikejackson]

Summary

ComputeFaceIPFColoring's Phase 2 branch uses m_CrystalStructures[phase1] instead of m_CrystalStructures[phase2] for both the crystal-structure validity guard AND the IPF-color operator lookup, while correctly pulling feature2's Euler angles and the flipped face normal. On surface-mesh faces where phase1 != phase2 AND the two phases use different Laue groups (e.g., cubic on one side, hex on the other), the Phase-2 face is colored using Phase-1's symmetry operator applied to Phase-2's Euler angles — produces wrong colors that look superficially valid (still in the IPF triangle).

Location

src/Plugins/OrientationAnalysis/src/OrientationAnalysis/Filters/Algorithms/ComputeFaceIPFColoring.cpp lines 114 and 123 (the Phase 2 branch of GenerateFaceIPFColoringImpl::generate()).

Sibling ComputeIPFColors.cpp (single-phase voxel-level) is clean because there's only one phase per cell — it uses the same phase variable consistently.

Provenance

• Original 2023 introduction in b3e45a4d73 (legacy GenerateFaceIPFColoring.cpp, authored by @jmarquisbq). The bug pre-dates the SIMPLNX port.
• Surfaced during an adversarial sweep on PR VV: EbsdLib 3.0.0 + V&V of 6 Filters #1631 (EbsdLib 3.0 + V&V of 6 OA filters).
• Already fixed in legacy DREAM3D v6_5_172 branch at commit 1c96b3b8e BUG: GenerateFaceIPFColoring — Phase 2 color used wrong-phase Laue ops (the 2-line phase1→phase2 change at lines 166, 175 of Source/Plugins/OrientationAnalysis/OrientationAnalysisFilters/GenerateFaceIPFColoring.cpp in /Users/mjackson/DREAM3D-Dev/DREAM3D).

Why this isn't fixed in PR #1631

The fix was applied in PR #1631 and then reverted because the existing test exemplar (OrientationAnalysis::ComputeFaceIPFColoringFilter: Valid filter execution) was generated from the buggy code — a textbook circular oracle. Applying the fix breaks the test. ComputeFaceIPFColoring is not in the 6-filter V&V cohort for PR #1631, so its exemplar was last regenerated against the buggy output.

The bug is currently documented in the source with a // KNOWN BUG comment block at the offending lines.

What this issue tracks

A full V&V cycle on ComputeFaceIPFColoring:

1. Hand-build a Class 1 (Analytical) toy fixture: a 2-feature surface mesh where Phase 1 is cubic, Phase 2 is hex, with closed-form expected colors for both face sides.
2. Verify the SIMPLNX algorithm (with the fix re-applied) produces the analytical-correct colors.
3. Re-generate the exemplar archive (or convert to inlined fixtures, per recent V&V cohort precedent).
4. Three source-tree deliverables: vv/ComputeFaceIPFColoringFilter.md + vv/deviations/ComputeFaceIPFColoringFilter.md + vv/provenance/....
5. Re-apply the fix at Algorithms/ComputeFaceIPFColoring.cpp:114,123 (phase1 → phase2).
6. Remove the // KNOWN BUG comment block.

The legacy v6_5_172 commit 1c96b3b8e already provides the corrected reference for empirical A/B validation.

Effect on users

Single-phase data is unaffected. Multi-phase microstructures with the two adjacent phases using different Laue groups (alpha/beta titanium, dual-phase steels, IN625 inclusions, etc.) will see wrong IPF colors on the Phase-2 side of mixed-phase faces.

cc @JDuffeyBQ @nyoungbq @jmarquisbq

[imikejackson]

Update — broader scope confirmed (2026-06-07):

After the revert was applied to PR #1631's branch, the ComputeFaceIPFColoringFilter: Valid filter execution ctest entry (#1190) still fails — meaning the exemplar mismatch is not solely caused by the phase2 bug fix. The same test fails on the post-revert (legacy, buggy-but-historical) code path against the pre-existing exemplar in 6_6_Small_IN100_GBCD.tar.gz.

This means the EbsdLib 3.0.0 upgrade (cf0f3307f on topic/ebsdlib_v3_updates) introduced an IPF-color output drift independently of the phase2 bug. Likely candidate: the HexConvention default + the _calcRodNearestOrigin quaternion-space rewrite both ripple through generateIPFColor for hex phases.

So the V&V cycle for this filter must:

1. Establish a Class 1 (Analytical) oracle for the filter (independent of any DREAM3D version).
2. Quantify the EbsdLib 2.4.1 → 3.0.0 IPF-color drift via empirical A/B against the legacy 6.5.171 / 6.5.172 binaries (which still use the pre-rewrite code path).
3. Regenerate the exemplar archive to match the corrected SIMPLNX-on-EbsdLib-3.0 output once both items above are done.
4. Apply the phase2 fix (phase1→phase2 at lines 114, 123) as part of the V&V cycle.

The phase2 bug fix is provably correct (sibling ComputeIPFColors.cpp uses the same pattern correctly because it's single-phase), but the test exemplar that's currently failing needs more than just that fix — it needs to be regenerated from scratch.