I have powder diffraction data (from SNAP at SNS), which I time-focused to d-spacing and then binned in 2theta using:
LoadIsawDetCal
Rebin
ConvertMatrixWorkspace
ConvertUnits
ConvertSpectrumAxis
Rebin2D (target d-spacing and SignedTheta)
But, between ConvertSpectrumAxis and Rebin2D, something strange happens to the 2theta values…
There are physically two (square, Anger) detectors in an equatorial plane that are asymmetrically positioned (det1: 80-130 deg (2theta); det2: 50-100 deg (2theta). They are in the correct position in a “show instrument” view after ConvertSpectrumAxis. But after Rebin2D the slice viewer shows counts that are symmetric for +/- 2theta both from 50 to 135 deg (i.e. similar to the total range, if the ttheta sign was neglected).
Any ideas? 
p.s. using the current stable release (3.13.0)
So far I’ve determined that it is a problem with ConvertSpectrumAxis giving the wrong values of SignedTheta in the output workspace. Also, there is a note in the docs for ConvertSpectrumAxis that says “After running this algorithm, some features will be unavailable on the workspace as it will have lost all connection to the instrument. This includes things like the 3D Instrument Display.” I need to look closer at the code for that before I can determine what is actually going on.
The loss of connection to instrument is that once you have replaced the spectrum axis with anything else it is no longer possible to determine which detectors a spectrum refers to. Therefore the 3D view or anything that needs position information afterwards is not possible.
This should itself not affect the signed theta calculation though, so if that is incorrect then that is a separate issue.
The documentation for ConvertSpectrumAxis isn’t explicit enough. When picking SignedTheta the sign is relative to what is defined in the reference-frame of the loaded IDF. When it is not specified (like SNAP), it is positive for things above the plane, and negative for things below the plane. I modified my local SNAP_Defintion_2011-09-07.xml to have its reference frame information defined as
<reference-frame>
<along-beam axis="z"/>
<pointing-up axis="y"/>
<theta-sign axis="x"/>
<handedness val="right"/>
</reference-frame>
which fixes the issue by making the sign positive for things pointing towards the positive x-axis as you described.
I will talk with the dev-team about changing the default to have the sign denote left/right as most people expect rather than up/down (the current default). This would fix it for most everybody. The ILL instruments already have this set.
Thanks for these suggestions. Can you let me know if there’s a way to direct mantidplot, running on the SNS analysis cluster, to a local instrument definition? I just tried to do this, I managed to find and copy SNAP_Defintion_2011-09-07.xml, but don’t know how to point mantid plot to a new location while it’s booting up. Cheers!
That part is “easy.” Put the updated file in your ~/.mantid.instrument/ and it should be picked up automatically. This is only the case for files that don’t already have the instrument definition in them (e.g. SNAP before the DAS upgrade in September 2018).
Just to confirm I think I got this working. Just putting the updated instrument XML file in .mantid.instrument/ did not work initially, but when I used the LoadInstrument algorithm, it was successfully read in. My 2theta values look to be correct.
As an aside, .mantid.instrument doesn’t show up in the LoadInstrument dialogue, but after copying to a non-hidden folder, I could find it and get it to work.