[Nexus] Triple Axis Spectrometer definition

[Mark Koennecke]

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. 

  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.

  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. 

  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
    * .....
     
  - 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.
  - NXcrystal, both analyzer and monochromator: I would expect motor values,
    motor zero points and energy values here. See general comment above.
  - 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.   
  - 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.

    Be warned: TAS is a tricky business!

		       Best Regards,

			    Mark Koennecke