Skip to content

VV: ComputeFeatureReferenceCAxisMisorientations fully V&V'ed#1636

Open
imikejackson wants to merge 1 commit into
BlueQuartzSoftware:developfrom
imikejackson:vv/compute_feature_ref_c_axis
Open

VV: ComputeFeatureReferenceCAxisMisorientations fully V&V'ed#1636
imikejackson wants to merge 1 commit into
BlueQuartzSoftware:developfrom
imikejackson:vv/compute_feature_ref_c_axis

Conversation

@imikejackson

Copy link
Copy Markdown
Contributor

No description provided.

Summary:
- Confirmed no SIMPLNX-side bugs (algorithm correctly handles
    all-non-hex feature via IEEE 754 NaN propagation; D1 + D4 below are
    pre-existing legacy bugs already fixed in SIMPLNX via PR BlueQuartzSoftware#1438 + PR
    BlueQuartzSoftware#1472);
- documented 2 deviations from DREAM3D 6.5.171 (D1 legacy lacks isHex
    gate → garbage non-hex cell values + non-NaN avg, D4 hand-rolled
    MatrixMath + float32 stddev precision drift ~1e-4° per cell) — both
    already closed on v6_5_172 via pre-existing backport commits
    d4b5509aa + 4435d1997, three-way A/B confirms 6.5.172 ≡ SIMPLNX
    byte-for-byte;
- retired 1 test (Valid Filter Execution — circular oracle on
    caxis_data.tar.gz exemplar; archive download retained because
    ComputeCAxisLocationsTest still consumes it);
- unit tests replaced with 4 inlined *Class 1 (Analytical) + Class 4
    (Invariant)* test fixtures (Simple Hex Triple + Realistic
    Microstructure exposes-all-non-hex-feature + All-Identical
    Orientation + Invariants sweep);
- added 3 V&V source-tree deliverables (report, deviations, provenance).
@imikejackson imikejackson force-pushed the vv/compute_feature_ref_c_axis branch from cf0ca21 to 7328371 Compare June 11, 2026 15:04
@imikejackson imikejackson requested a review from nyoungbq June 11, 2026 17:02

---

## ComputeFeatureReferenceCAxisMisorientationsFilter-D4

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unclear numbering scheme it goes from D1 straight to D4

| **Filter UUID** | `16c487d2-8f99-4fb5-a4df-d3f70a8e6b25` |
| **Status** | active (SIMPLNX fixed pre-V&V via PR #1438; legacy 6.5.171 still has the bug — backported to `v6_5_172` branch in commit `d4b5509aa`) |

**Symptom:** Per-cell and per-feature outputs for non-hex features differ between SIMPLNX and DREAM3D 6.5.171. Legacy 6.5.171 computes a c-axis projection misorientation for *every* cell regardless of crystal structure, producing meaningless numeric values for non-hex cells (the projection treats the cubic cell's quaternion as if it were hex). For a feature whose cells are *all* non-hex, the legacy filter produces `featAvg = 0.0 or whatever-the-projection-yields` instead of the analytically-correct `NaN` — the per-cell loop accumulates numeric values into the avg, and the final division produces a finite result. The per-feature population stddev follows the same garbage pattern.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**Symptom:** Per-cell and per-feature outputs for non-hex features differ between SIMPLNX and DREAM3D 6.5.171. Legacy 6.5.171 computes a c-axis projection misorientation for *every* cell regardless of crystal structure, producing meaningless numeric values for non-hex cells (the projection treats the cubic cell's quaternion as if it were hex). For a feature whose cells are *all* non-hex, the legacy filter produces `featAvg = 0.0 or whatever-the-projection-yields` instead of the analytically-correct `NaN` — the per-cell loop accumulates numeric values into the avg, and the final division produces a finite result. The per-feature population stddev follows the same garbage pattern.
**Symptom:** Per-cell and per-feature outputs for non-hex features differ between SIMPLNX and DREAM3D 6.5.171. Legacy 6.5.171s c-axis projection treats every cubic cell's quaternion as if it were hex. For a feature whose cells are *all* non-hex, the legacy filter produces `featAvg = 0.0 or whatever-the-projection-yields` instead of the analytically-correct `NaN`. The issue exists in the per-feature population stddev calculation as well.

This needs to be consolidated see above for example

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants