Bragg peaks at high Q_z values are sometimes not found

[Finnjek]

The calculation of Bragg peaks is systematically not finding Bragg peaks with high Q_z values in our latest CTR datasets of Pt(110). The peak positions are calculated in ReciprocalNavigation.py, in the function thscanBragg():

Qmax = sxrddetector.Qmax # np.abs(sxrddetector.qArray()).max() / 10. # to Angstrom-1

hkls, angles = anglesAllowedReflections_G(xtal,None, alpha,Qmax,**keyargs)

It seems like the calculated Qmax is not correct, the problem can be fixed by adding an arbitrary value to Qmax when calling anglesAllowedReflections_G()

[Finnjek]

see commit 9f3ce20

[tifuchs]

I was working on this bug before and thought that Qmax isn't the problem anymore.

I added test code for that a while ago in orgui\datautils\xrayutils\test\test_DetectorCalibration:
TestAnglePixelConversion.assertQrangeValid

There is a small discrepancy between sxrddetector.Qmax (which is a fast computation) and the numerical np.abs(sxrddetector.qArray()).max() / 10.
, which is the exact but slow (approx. 1-2 s) solution.
I think the tests are passed with 1e-5 precision.

Could you verify that this bug is caused by Qmax?

I don't like adding +10 to Qmax. This might work for Pt, which has very few Bragg reflections. Adding +10 to Qmax adds maybe 50 more Bragg reflections for Pt, which is fast to compute. However, for anything with a slightly larger unit cell, adding +10 to Qmax would add hundreds or even thousands more (potential) Bragg reflections. This would freeze the software.

There is an obvious bug in ReciprocalNavigation.allowedReflections_G:

hklmax = np.floor(maxQ/b).astype(np.int64)

This is incorrect, since the actual Q of a Bragg reflection must take into account the angles between lattice vectors. Correct is

$$ Q_{hkl} = \left| \mathbf{B} \cdot \vec{H}_{hkl} \right| $$

where $\mathbf{B}$ a matrix that transforms the reciprocal lattice vector $H_{hkl}$ into cartesian coordinates. So we would need to invert the equation above to get $H_{hkl}$ for all $Q_{max}$.

def allowedReflections_G(xtal: Union[CTRcalc.SXRDCrystal,CTRcalc.UnitCell],maxQ: float = 12.0,**keyargs):
    if isinstance(xtal,CTRcalc.SXRDCrystal):
        b = xtal.uc_bulk.b
        #_,_,b,_ = xtal.uc_bulk.getLatticeParameters()
    else:
        #_,_,b,_ = xtal.getLatticeParameters()
        b = xtal.b
    hklmax = np.floor(maxQ/b).astype(np.int64)
    if 'negative' in keyargs and keyargs['negative']:
        h = np.arange(-hklmax[0]+1,hklmax[0])
        k = np.arange(-hklmax[1]+1,hklmax[1])
        l = np.arange(-hklmax[2]+1,hklmax[2])
    else:
        h = np.arange(hklmax[0])
        k = np.arange(hklmax[1])
        l = np.arange(hklmax[2])

[Finnjek]

Thank you for the detailed reply!

I first tested if the fast Qmax calculation gives roughly the same value as the numerical one (like in the test code). The result is 5e-4 precision, which is not ideal but definitely not the issue in my case.

I also tested the gamma and delta ranges calculated by DetectorCalibration.py, giving a maximum value for gamma of 17.09 degrees - which is a bit below the originally missing Bragg's angle in the CTR scan. The actual maximum gamma at the upper edge of the detector is about 18.1 degrees in this scan.

Even though the peak can't be found using the allowedReflections_G() function, the CTR tracking and allocation of Bragg peaks using the reciprocal space navigation tab still works without any issues.

I agree that a correction by adding 5 $\AA^{-1}$ may not be the best idea. Instead I propose to add a correction factor of 10% to the calculated Qmax value until the bug in the calculation is found.

[tifuchs]

There should be two different versioins dc.rangegamdel. One ( dc.rangegamdel), which should calculate the actual gam, del versus the surface tilted by alpha. dc.rangegamdel_p calculates del, gam versus the primary beam position. Can you upload the poni file?