[Nexus] Triple Axis Spectrometer definition

[Mark Koennecke]

Nick,

On Mon, 4 Aug 2003, Nick Maliszewskyj wrote:

> Greetings Mark,
> 
> >   High Nick,
> > 
> >   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.
> 
  This WAS a bad solution!

> 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)?
> 
  I have two concerns with this:
  - A NXdata group with ~30 arrays will be very confusing to a casual
    user.
  - Some of the data, especially when not varied in the scan, belongs IMHO
    to the components associated with them.
  But I agree, there is no harm done by having the whole lot in NXdata.
  Perhaps somebody else might comment on this?

  The reading bit is IMHO a no issue. I may sound like a double-glazing
  salesman now, but with NXdict you can read any dataset in one function
  call, no matter where in the file it is. 

> >   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.
> 
  OK.

> 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?
> 
  Common usage at PSI is to keep the motor positions with the device they
  are associated with. Monochromator moving motors to monochromator,
  sample moving motors to sample etc. This is what I instinctively came up
  with and I still think this is sensible decision.

> >   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
> 
> 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?
  
  This suggestion is based on my experience. I'am getting calls even from
  experienced users who complain that nothing works like it should. Quite
  often the problem is that the mode has not properly been selected. Our
  instrument scientists insisted on a TASMAD syntax for their TAS, so I'am
  running a MAD emulation on top of SICS. And there the mode is hidden in
  a number of variables. 
> 
> >   - 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.
> 
  Interesting, can you give me a reference on this one? May be I come 
  down to doing the TAS stuff properly in some stage....

> 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.
> 
  You are right, this is an issue. Nearly every fourcircle has its
  own system for dealing with UB matrices. Perhaps this is an issue which
  should be discussed at the NeXus  Advisory Commitee meeting.  

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

> >   - 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.
> 
  Ah well, give me a link!

> 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.
> 
  I would put this to the monochromator or analyzer. NXbeam always was
  optional.

> >   - 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).
> 
  So this is reduced to a current then! I could live with that.

> >   - 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.
> 
  I tried once, for a TAS. But this was my very first attempt to do a 
  NeXus file (in 1996?) and so I considered it not worth posting. 
 
> 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.

  I pondered this for another instrument, AMOR. This is how I came up
  with my solution. I think there are several ways to solve the scan 
  issue:
  1) Your solution: keep anything movable in NXdata.
  2) My solution: keep anything fixed with the components and have
     only the scanned stuff in NXdata.
  3) Keep arrays for positions at the components and link the scanned
     variables into NXdata. 
  IMHO, 1 is messy, 2 runs into problem if you have motors connected
  to another variable, for example A5, A6 are linked to ef, Kf. My
  current favourite is 3. 

  I hope somebody else happens to be not on holiday and is available for
  comments on this.


                            Regards,

					Mark Koennecke