[Nexus] Triple Axis Spectrometer definition

[Nick Maliszewskyj]

Peter,

Thanks for weighing in.

Peterson, Peter F. wrote:
 > Nick,
 >
 > First I would like to put in a plug for the NeXus swiki at
 > <http://www.neutron.anl.gov.:8080/NeXus> which would be a better
 > place to post the definition since people can edit it without sending
 >  the file back and forth (under 'NeXus instrument definitions'). This
 >  also allows for definitions to be pulled out and added to the NeXus
 > site at a later date.
 >
Your point is well taken. I'll post the definition to the swiki
pages. At this stage, however, the mailing list seems to be a
better forum for soliciting input from developers at large.

BTW, what is the mechanism by which definitions are pulled out and
added to the NeXus site? As far as I can tell we have no formal
acceptance procedure and there are only two instrument definitions
and a number of class definitions. Furthermore, it appears that we
have two types of definitions: those that people are using and
haven't posted and those that are posted and people aren't using.

 > Correct me if I misread your message,  but it seems as though you
 > want to store the data with redundant axes. I agree with Mark that
 > only quatities that are varying in the scan should be in the NXdata,
 > but redundant axes could be very useful. This is a very interesting
 > idea since who knows better how to convert detector positions to
 > (Qx,Qy,Qz,E) than the person running the instrument and writting out
 > the data? Would it make sense to have a 'signal'-like attribute on
 > the axes as well as the data to sort out which set of redundant axes
 > go together? Of course, the more flexible you make the standard, the
 > tougher you make life for those trying to make a generic reader, so
 > we should be careful.
 >
I think you have read my message essentially correctly. In each NXdata
group we would like to store the vectors of independent scan variables
(with suitable references in the "counts" portion to distinguish them
as "signal" variables), while also storing the positions of every
other observable. Fundamentally, the scan variable(s) and the
accumulated events collectively form the "standard". All other items
are supernumerary and can be safely ignored. My understanding is that
a generic reader would follow the "automatic plotting" rules to
associate dependent and independent variables. By including the
additional information, the job of plotting counts vs. other quantities
will be made simpler (it's all in the same place). Any other storage
requires much more complicated mining of the data.

 > About the TAS definition in particular (WARNING I have limited TAS
 > knowledge): could the instrument borrow definitions from other
 > instruments depending on the mode it is running in. For example, if
 > you are performing an elastic powder measurement you could use
 > 'mononxpd'. Only in the case when your measurement cannot be
 > described by something else would you fall back on the TAS
 > definition. Remember that each NXentry can be a different analysis
 > type.
 >
While in spirit it is possible that the instrument could borrow
definitions from other instrument types, to try to pigeonhole
measurements into a few classes imposes just the sort of rigidity
that we are at present trying to avoid. This is an expert's technique
and we should endeavor to record the data in such a way that
arbitrary scan trajectories can be accommodated.

 > Finally, some notes about your file NXmononxtas.xml: - Any tag that
 > does not start with 'NX' is assumed to denote the name of the group.
 > If you do not define a type it is assumed to be 'NX_CHAR'. - For your
 >  'NXdata' you have some coments describing what is going on. I
 > recommend that you change the 'NXdata' start tag to be: <NXdata
 > name="off-off|off-on|on-off|on-on"> That way validation code can more
 >  easily use it.
 >
 > Peter Peterson
 >
Mea culpa. I'll make the necessary edits to bring this file back in
line stylistically (or you can when I add this to the swiki). At this
stage, I felt it was important to furnish some sort of "cartoon"
version of the proposed organization so that some of the discussions
taking place could happen.

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