Symmetrical HKLs included after new transforms

[psavery]

It appears that symmetrical HKLs are being included after hexrd/hexrd#509 was merged.

Labeling HKLs for some Laue overlays used to appear like this (before that was merged):

But now appear like this:

We should figure out why symmetric HKLs are not being identified correctly.

This issue is apparently not angles_to_gvec (I checked that one). Must be either gvec_to_xy or make_sample_rmat.

[psavery]

Upon studying this further, we see that the issue lies in gvec_to_xy, and what it does with +g vs -g.

Taking a look at one of these spots, we saw two different g vectors being input: [-0.90453403, -0.30151134, 0.30151134] and [ 0.90453403, 0.30151134, -0.30151134]. We can think of one as +g and the other as -g. In the new xrd transforms, these both result in an xy output of [ -5.24220836, -17.28574434]. However, in the old xrd code, one of them would be set to nan.

We need to think about what to do about the +g versus -g case. Do we need the new transforms to match the old behavior, or do we need to filter out -g before passing it to gvec_to_xy?

Here's a test scrip that shows the difference (we are still able to call the old function in hexrd):

test_laue.zip

In this script, gvec = args[0], and gvec[314] is the first g vector mentioned above, while gvec[309] is the second vector. The old function would return nan for gvec[309] (where gvec[309] == [ 0.90453403, 0.30151134, -0.30151134])

[psavery]

After even further testing, the following was observed:

1. The old gvecToDetectorXY would return nan for some gvec values (one of +g or -g). But the old gvecToDetectorXYArray would not return nan for these values.
2. In the HEDM workflow example we tested, gvecToDetectorXY was called in some places, but never with a g that would result in a nan as described in 1. Thus, we did not encounter this issue while testing the HEDM workflow.
3. The places we need to watch out for are places where gvecToDetectorXY were previously called, because these sometimes resulted in nan values where the new gvec_to_xy does not. That is the cause of this Laue issue.

[psavery]

It appears that I get the same results as we had before if I only keep the g-vectors whose z-component is opposite in sign compared to the beam vector's z-component. So I guess the old gvecToDetectorXY was doing this - maybe intentionally? I'm not sure.