[NeXus-committee] Inverse TOF, MARS

[Mark Koennecke]

High,

I am just trying to establish a data format for our upcoming MARS 
instrument. Schema attached.
I started wondering if we will ever find a standard instrument. Thereby 
a couple of questions arose:
- The instrument has 12 elastic-TOF detectors. These should in principle 
be covered by the TOFNPD
   description. The first question here: is it really sufficient for 
data reduction to know the  histograms in
   the detector and the monitor without any chopper data?   I will add 
chopper information anyway.
- The inelastic part is more complicated: There are 12 triffids at 
various polar angles to the sample.
   Each triffid caries an analyzer which moves up out of the sample 
plane and scatters neutrons into
   detectors sitting below. I.e. the scattering plane is vertical in a 
given triffid. 
  * The first decision I tend to make is to treat analyzers and 
detectors as one bank each, rather then
     having a NXcrystal and a NXdetector group for each triffid. All 
analyzers and the detectors are the
     same and are expected to be moved to the same setting at most 
times. Anyway all settings can be
     treated as arrays.
  * The second question is how to describe the position of the 
analyzers. They could be described by
      two theta and a tilt angle out of plane. Two theta maps to polar 
angle, but I'am not sure that the
      azimuthal angle maps to the tilt. In fact, in the use case with a 
triple axis  the azimuthal angle make sense
      only when it is a rotation around a vector from the sample towards 
the analyzer. This would cover my case
     only when the azimuthal angle would be combined with some length 
along the azimuth. We have no tilt
     angle anywhere in the DTD's. Anyway, this is what I would suggest 
for such a situation:
    + polar angle, like longitude in a spherical coodinate system, 
incoming beam 0, tilt corresponding
      to latitude in a spherical coordinate system.
  * The third question is how to handle the scattering angle of the 
detector towards the analyzer.
     Rather then treating this vertical situation with yet another 
coordinate system, I would package
     that as a tilt angle.

All together the NeXus file for this will have two NXentry groups: one 
elastic matching TOFPNG and another
one inelastic matching ?????

What do you think?

May be I am only confused about these coordinates and there is a simple 
solution to this. Anyway, if I
get confused on this, how would the ordinary NeXus user fare? Therefore 
I suggest to write a section on
our two coordinate systems (angles plus distance and NXgeometry) in the 
WWW and the docs. As these
coordinates are common to  all component definitions, they should be 
removed from the component DTD's
and kept separate with the statement that these can occur in any 
component DTD.

I do not know if this only went into nexus-developer, so I state another 
problem again here. Hartmut Gilde
raised the problem of having links to two SDS with the same name but in 
separate groups in a NXdata
group. Example: TAS: analyzer/energy and monochromator/energy. I did 
some research on this and
found that it works with HDF4 an d XML and not with HDF5. There is no 
easy fix for the HDF5 problem as
HDF5 internally works with path strings. It is about the same problem 
why you cannot link two files onto the
same linkname in a unix file system. Anyway, even with HDF4 and XML 
NXdata then is confusing:
you have two items in there saying energy and only the link target 
strings tell you what is what. This ought
to be clearer: Therefore I suggest to use more qualified names in such 
cases where data is linked, i.e
analyzer/analyzer_energy and monochromator/monochromator_energy.

                                      Best Regards,

                                                      Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mars.png
Type: image/png
Size: 738954 bytes
Desc: not available
Url : http://lists.nexusformat.org/pipermail/nexus-committee/attachments/20050728/71f7d4a0/attachment.png