Make units for "Q" consistent

[Janik Zikovsky]

Here is what I suggest:

1. For momentum transfer, we should use 2*pi/d=2*pi*dstar

2. For MD we use Qlab=2*pi*G*UB*(hkl), where G is the Goniometer rotation matrix. In this notation, Bragg peaks are at integer hkls.

3. The above formula addresses all the conversion problems. There is no need to change OrientedLattice, we just need to make sure all algorithms correctly implement the UB matrix formalism. If more programmers really want this, we can implement a function called get2PiUB() {return getUB()*2*M_PI;}, but I don’t think it’s necessary.

We can discuss it during the VATES meeting tomorrow.

Sincerely,

Andrei

---

From: nick.draper@… nick.draper@…

Andre,

We have a problem and it’s something we urgently need to address before the release. We have two definitions for |Q| and this will be plain embarrassing when as this is picked up by more users. In mantid convertunits |Q| is defined as 2pi/d, while in the OrientedLatice work for Vates |Q| is 1/d. Clearly we can not leave it in a situation where Q means two things in different areas of Mantid, and as VATES is the relative newcomer then that is the one that will have to change. Pascal over here suggested that we could use s as a unit for 1/d to differentiate it, but only if we need to keep both.

So first the questions:

1) Do we need to have a unit of 1/d? Could we just go with 2pi/d? Or do we need both?

2) If we call 1/d s, then do we need to be able to choose between SxSySz and QxQyQz dimensions when creating MD workspaces?

3) Would changing the value used by the oriented lattice from 1/d to 2pi/d affect any of the existing algorithms?

Then the action:

Depending on your answers to the questions we urgently need to do something about this so this discrepancy is not continued into the release in January. Could you either replace 1/d with 2pi/d or add the capability of both depending on your answers to the questions, and then in either case Test that this does not interfere with any of the algorithms that use the affected methods.

Regards,

Nick Draper

---

From: Arnold, Owen (-,RAL,ISIS)

I’ve been investigating the issue reported by Jon Taylor regarding units of Q. It appears that we define Q to be in units of spatial frequency. This behaviour is coded into several algorithms and the OrientedLattice. As users at ISIS will want to treat |Q | = 2Pi/d_spacing according to the physics definition of reciprocal space, we’ll have to set our algorithms up to cope with both.

First of all, I suggest following Pascal’s suggestion of calling the existing Q, S. Then Q would refer to the physics definition of the reciprocal lattice. I then suggest that our conversion algorithms such as ConvertToDiffractionMDWorkspace give the option of doing the conversions in terms of S and Q. Another possibility, although might be too heavy-weight, would be to abstract OrientedLattice and have a version that deals with Q and one that deals with S depending upon how deep the changes need to go.

[Janik Zikovsky]

Refs #4350 start of fixing Q in MD-stuff

... to use 2 pi / wavelength. FindUB* tests are still failing.

Changeset: 895b8adec1d21294cc2d1e0595ae7b576eeadd1d

[Janik Zikovsky]

P.S. Working on a separate branch "fix_q_units"

[Janik Zikovsky]

Refs #4350 : added 2 pi factors in indexing utils

and indexSXPeaks that make them consistent and unit tests pass for the new Q convention in the Peak object.

Changeset: 1e439215833ccebd6f94e4bf07a45726f6153807

[Dennis Mikkelson]

The algorithms to find a UB matrix given peaks, and to index peaks, use a PeaksWorkspace. They assume that the Q-vectors obtained from the PeaksWorkspace correspond to |Q|=1/d. IF the PeaksWorkspace is changed to return Q-vectors corresponding to |Q|=2PI/d, the algorithms will need to divide the Q vectors by 2PI, before passing the Q vectors in to the IndexingUtils methods. The five algorithms are: FindUBUsingFFT, FindUBUsingIndexedPeaks, FindUBUsingLatticeParameters, FindUBUsingMinMaxD and IndexPeaks.

Dennis

[Janik Zikovsky]

OK I just merged the branch fix_q_unit into "master".

Dennis - before your email, I had already modified the methods in IndexingUtils to divide Q by 2*pi when reading them in; and I left the FindUB* algorithms unchanged. I also had to multiply your test Q vectors by 2 pi.

In the end, this is equivalent and all the unit tests pass. It has the added side benefit of making Q consistent in IndexingUtils with the rest of the program.

I tested the algorithms with ConvertToDiffractionMDWorkspace, FindPeaksMD and FindUB* and IndexPeaks, on some TOPAZ data and all seems consistent, peaks index well.

[Janik Zikovsky]

Refs #4350: Make HKL correct in ConvertToDiffractionMDWorkspace

Changeset: 5edb693b57c2829e6653fd6facdbabe433343d0d

[Owen Arnold]

These two new algorithms are currently hard-coded to work with |Q| = 1/d_spacing: FindSXPeaks, IndexSXPeaks. I can provide more details if it's not obvious where this is happening.

[Nick Draper]

Moved to iteration 33 at iteration 32 code freeze

[Andrei Savici]

Changes to InstrumentWindowPickTab. Refs #4350

The knorm is no longer divided by 2Pi. I also added the goniometer to the peak

Changeset: d64def4dec7f61ce09f69b08b736262780d42f87

[Andrei Savici]

Changes to InstrumentWindowPickTab. Refs #4350

The knorm is no longer divided by 2Pi. I also added the goniometer to the peak (cherry picked from commit d64def4dec7f61ce09f69b08b736262780d42f87)

Changeset: 011f51ab909e2c81584c69741cd52fd0eab00174

[Roman Tolchenov]

Compared wavelengths from the same peak (WISH data) with the two releases: the 2.0.2 number is smaller by a factor of 2*PI.

[Stuart Campbell]

This ticket has been transferred to github issue ​5197