[Nexus] Triple Axis Spectrometer definition

[Nick Maliszewskyj]

Greetings Mark,

Thanks for the quick turnaround. I'll try to reply in kind.

Mark Koennecke wrote:
> 
> 
> On Wed, 30 Jul 2003, Nick Maliszewskyj wrote:
> 
> 
>>Greetings,
>>
>>The NCNR is in the process of building a state of the art triple axis
>>spectrometer on our BT7 beam tube which should go into operation by
>>early 2004. As a part of this undertaking, we are redesigning our
>>software for triple axis spectrometry and are making the step of
>>breaking away from our traditional formatted ASCII data file format.
>>
>   High Nick,
> 
>   in your e-mail you stated you welcome comments on your triple axis
>   definition. Well, I have lots of them. 
> 
>   Generally I think it is a good idea to keep the datasets for different
>   spin flipper states in different NXdata groups. 
> 

OK. This should accommodate most modes of operation, from unpolarized
beam to every set of cross sections (sometimes our experimenters only
measure two cross sections).

>   I'am less convinced that it is a good idea to have arrays of all relevant
>   values (Q,E, motors) in the NXdata group (May be I misunderstood your
>   definition here). In fact we have to make a 
>   more fundamental decision here how to handle scans in NeXus. I suggest to
>   keep arrays of only the values varied through the scan in NXdata and the 
>   fixed values at the components where they belong (E at monochromator,
>   analyzer, HKL at sample etc.). Otherwise NXdata quickly becomes
>   unwieldly. Our TAS has 20 motors plus the Q-E variables plus magnetic
>   fields plus sample environment. And most of those motor get scanned 
>   during alignment scans. Ahh, and if you replace fixed values at component
>   level through links to arrays in NXdata you can still recover full Q-E
>   information by traversing the component hierarchy.
> 

I think here we must talk philosophy. Our instrument control software
has traditionally recorded the experimentally germaine independent
variables (Qx,Qy,Qz,E, or motor angles in laboratory coordinates).
Positions of the motors moved to change momentum or energy transfer were
not recorded, and neither were the positions of any motors held fixed
during the scan. This made it very difficult to back out data in the
event that problems were encountered.

In the spirit of saving ourselves from unnecessary grief, we choose to 
store all experimentally observable quantities, as well as the relevant
quantities derived from them. As long as the actual "data" in the NXdata
group satisfies the criterion of indicating what the independent
variables are, what is the harm to be done in recording the additional
information (particularly if it makes life easier for applications
_reading_ our data)?

>   Another more general concern are the motor zero points. This is a hot topic
>   which can stirr a lot of arguments. In TAS experiments they frequently 
>   align their samples and set new zero points. Now is the question: which
>   motor values go to file? The "physical" values, with zero points applied
>   or the "real" values read from the motor controllers. At PSI we settled for
>   the "physical" values, but we store the zero points for each motor. Thus
>   we may be able to recover the actual position of the instrument on the
>   floor. 
> 

Your approach to recording motor positions is a sensible one.
Fundamentally, my assertion that experimental observables (in
this case axis positions as read from mechanical verniers) should be
recorded argues that the "real" values should be stored. My instrument
scientists, however, would prefer the "physical" angles be stored. So
as long as we can recover the "hardware" angles from them and their
offsets (in our world, software = hardware - zero), this should be an
acceptable deviation.

On the subject of motors, I have wondered what is the best way of
addressing the motor control infrastructure. The NXinstrument group
and its members have focused primarily on the measurement optics and
items that sit in the beam while never explicitly referring to the
machinery that positions them. For simple positioning of a crystal
monochromator or analyzer, we could specify the takeoff angle in
"physical" coordinates with the offset/zero as an attribute of that
element. This approach could work as well for my collection of motor
vectors in the NXdata group, but things like motor offsets are really
attributes of the instrument proper. Should there be a separate
"NXmotor" element in the NXinstrument group?

>   Now a few comments ordered by groups in your suggested XML definition:
> 
>   - NXinstrument I thing a string telling me about the mode of operation
>     would be very helpful. TAS have so many modes of operations that even
>     seasoned users can get confused:
>     * powder mode
>     * fixed KI
>     * fixed KF
>     * .....
>      

This is fair enough, but many measurements may not fit easily within
a standard label. Why not just let the NXdata group speak for itself
in this regard?

>   - NXsample. You mention  a UB matrix. Are you using a eulerian cradle
>     at TRIAX? If so I would expect to find the chi, phi, omega motor
>     settings in NXsample as well. If you are using the traditional TAS
>     setup, with orienting vectors, I would expect their values in NXsample
>     instead.

We are using nesting tilts on several of our triple axis instruments, 
and an eulerian cradle on one. At Oak Ridge, Mark Lumsden and Lee
Robertson have adapted Busing and Levy's UB matrix formalism to
tilts, we were thinking along the same lines.

As I was composing this definition it occurred to me that what we
include in a data set in many cases is dictated by the practices by
which we conduct measurements. There are at least two ways I am aware
of that crystal orientation is specified, and both merely serve to
effect the transformation of reciprocal lattice vector to goniometer
angles. The real question here is how portable should even this piece
of the data file be? We may choose to record it just to have a record
within the data file, but unless the same conventions for specifying
orientations are used universally, this information will be irrelevant
for interchange.

How do you prefer to record sample orientation information? We currently
specify one vector along omega == 0 and another within the scattering
plane.

>   - NXcrystal, both analyzer and monochromator: I would expect motor values,
>     motor zero points and energy values here. See general comment above.

You can expect them, but the motor values and therefore energy values
may all vary during a scan.

This brings me to another question. Where is the best *default* place to
specify the wavelength of the probe incident on the sample (for the
purposes of elastic scattering measurements)? There is a note on the
NeXus_contents page that an NXbeam group inside the NXsample group could
serve such a purpose, but the "energy" element in the NXcrystal group
associated with the monochromator would suit as well.

>   - NXflipper groups. I fail to understand the point about all those _turns
>     variables. For me a flipper is a magnet. And in order to describe a magnet
>     fully I think I would require far more parameters (dimensions etc). May
>     I suggest to replace this by a vector describing the magnetic field at the
>     flipper with respect to our coordinate system? I believe we aggreed to 
>     use the McStas coordinate system for such things.   

Yes, a flipper is basically a magnet. But it's a magnet whose field
strength must be tuned to the energy of the neutron passing through
it. For our flat solenoid flippers, this is done by changing the current
passing through them. For a given neutron energy, it is sufficient to
specify the "on" current required to flip the neutron spin over the
thickness of the flipper. While you _can_ record the flipping field, I
believe that we should rather record the experimentally observable
quantity (the current), from which the field could be derived (in
combination with the _turns variables).

>   - NXdetector groups. Are the size and gas pressure values really needed?
>     Are these value measured? Usually the efficiency which is calibrated in 
>     some stage somehow should be sufficient here.

To be honest, the size and fill pressure values are not terribly
relevant to the storage of the data. As most measurements tend not
to be absolute, even efficiency (which again varies with the energy
of the neutron) is only really useful for normalizing counts
in a bank of detectors (i.e., it may be irrelevant in the case of
a single detector).

>     Be warned: TAS is a tricky business!

Triple axis spectrometry is perhaps the most "flexible" instrument
type, and in truth there are relatively few variable types that can
be considered scalars for all posterity. Specification of this data
format is a tougher proposition than for the "sit there and accumulate"
types of instruments, and this perhaps explains why noone has yet done
so...or at least why any efforts have not been posted.

There are quite a few "move and count" experiments out there,
so addressing these issues for triple axis instruments should
provide a payoff in terms of defining other scan-based
measurements.

Nick

-- 
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
o Dr. Nicholas C. Maliszewskyj
o Center for Neutron Research
o National Institute of Standards & Technology
o 100 Bureau Drive, Stop 8562
o Gaithersburg MD 20899-8562
o nickm at nist.gov
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo