NeXus standard

[Tim Mooney]

re...
> > I am currently working on a tool to store our scan data into NeXus files.
> > We have a 1D scan modules that can be programmed to move positionners and
> > read detectors.
> > By linking scan modules together we can acquire multidimensional datasets.
> > ...
> > Their are some problems to store this kind of data into NeXus.
> > 1) the pos1_1 is the X axis for det1_1 but the Y axis for det2_1 so I need
> > to duplicate the data to give each copy a different axis attribute.
> > 
>   Eric,
> 
>   I'am afraid I do not fully understand the problem. To me a 2D scan is a
>   2D dataset somehow like this:
> 
>        pos1 ->
>   pos2 ******************************************
>    |   ******************************************
>    V   ******************************************
>        ******************************************
>        ******************************************
>        ******************************************
>                 .
>                 .
>        ******************************************
> 
>    with pos1 being the first axis varied and pos2 the second. I would
>    store this then as:
>       SDS counts(2D), signal = 1
>       SDS pos1, axis = 1
>       SDS pos2, axis = 2
> 
>    Why is this bad? ...
> ...
>    Any further opinions? 
> 
>    
>    Mark Koennecke

One problem is that multidimensional data do not always (or even
usually) have a simple structure.  Let's take the case of storing
fluourescence spectra as a function of some variable (say, time, for
simplicity).  The obvious way to store these data is in a 2D array,
where each row is a multichannel analyzer spectrum.  But along with
each spectrum are a number of scalar data, such as the MCA live time
and real time, the beam current, the signal from an ionization chamber
integrated over the MCA acquire time, the signal that indicates beam
steering, tuning, or top-off injection occurred during acquisition of
the spectrum.  These scalar data can't be plotted against the X axis of
the 2D data set, which is the MCA channel number or something derived
from it.  They have to be plotted against the Y axis of the 2D array,
but this axis has declared itself to be a Y axis (i.e., axis = 2), so
we must make another copy of the same data and have this copy call
itself an X axis.  In this case it would be better if the data to be
plotted could indicate what axis level should be its X axis, etc.

The real case I'm drawing from is of fluourescence microtomography,
which produces a 4D data set (a series of 2D images at different
angles, each pixel of each image has a fluourescence spectrum
associated with it--several, actually, because several x-ray detectors
are required to get this data in a reasonable time).  The axes are the
following:

4: image number (rotation angle)
3: Y pixel address (Y "motor")
2: X pixel address (X "motor")
1: fluourescence energy (MCA channel number)

With this data set, we're going to have some 1D arrays plotted against
axis 4 (e.g., integrated beam during acquisition of each image), and
others plotted against axes 3 and 2.  Each rotation angle also will have
conventional x-ray image (e.g., transmission) associated with it, and
these images want axis 3 to be their Y axis and axis 2 to be their X
axis.  The spectra themselves, of course, want fluourescence energy to
be their X axis.

-------------

The other problem is 2D scans in which the X axis varies systematically
from row to row.  The usual reason for doing this is to avoid wasting
beam time acquiring data far from the peak, when you know approximately
how the peak will shift as the Y motor varies.  The result is an image
with blank regions where data were not acquired, and you really would
like not to have to regard these data as a series of separate scans.
If you do split the image into separate scans, and you have
mixed-dimensional data, as described above in the spectra vs. time
example, it's a hard job collecting scalar data to be plotted against
the Y axis.

Tim Mooney (mooney at aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab