Storing repeating structures in NeXus files

[Mark.Koennecke]

On Wed, 3 Nov 1999, Ray Osborn wrote:

> on 99/11/3 10:35 AM, C.M.Moreton-Smith at rl.ac.uk at
> C.M.Moreton-Smith at rl.ac.uk wrote:
> 
> 
> 1) Periods:  The periods that Chris is referring to are very like the frames
> that Mark discussed.  In both cases, my preferred solution would be to add
> an extra dimension to the NXdata.   In my experience, there are usually only
> a handful of periods.  For example, there may be only two periods to store
> flipper-on and flipper-off data; these should definitely be stored as a
> single dataset with an extra dimension of size 2.  You can then use
> NXgetslab to extract each set of data.  You can have many more periods when
> they are used in alignment scans, e.g. on PRISMA, but that is a fudge to
> disguise the inflexibility of the standard ICP to cope with scan data.  The
> data are still much better stored as a multidimensional array; they will be
> much easier to plot and analyze.

  I still do not fully understand what periods are, but: flipper-on
  flipper-off polarized data is something I would store as different
  entities alltogether. So, I would rather have a 3D array with time
  binning etc for flipper on and another one for flipper-off. 

  Scan data is something I suggest to store as arrays of length NP each
  for the scan variables, counters and monitors. In the unlikely event
  that you scan a PSD I would not hesitate to hae an array of
  PSD[dims][NP]. In a scan the experiment logic gives meaning to it. I
  implemented it that way but as the instrument is not operational I can
  still change it. I'am discussing 1D scan only so far, for 2D I would
  need to think..

> 
> 2) Time regimes: When I was at ISIS, no instruments had more than one time
> regime because each regime required a new crate, which was expensive.
> Surely no instrument has more than a few even now.  Since each time regime
> has a different set of time channel boundaries, they clearly need to be
> stored in separate NXdata groups.  However, this is no different from
> storing different detector banks in different groups - they can be called
> whatever you like (bank1, 4m_bank, low_angle_bank etc.)  They don't
> logically form an array since there is no obvious variable linking them.

  I fully agree, detector banks with different time regimes should go in
  separate detector and NXdata groups.
> 
> > A smaller scale and more ISIS specific example is that of sample environment
> > parameter blocks which are already stored as an array of similar
> > heterogeneous structures, one for each piece of sample environment equipment
> > on the CAMAC control system.  Writing these as separate arrays is
> > incovenient, if only because some would have to be arrays of strings (sample
> > block names).
> > 
> 
> Again, I believe that we are talking about a handful (perhaps up to 20?)
> sample blocks.  Actually, putting all the sample blocks into groups called
> "1", "2" etc, will make it much more difficult for the user to find the one
> s/he's interested in.  Surely, s/he would prefer to find groups called
> "Temperature" or "Sample_changer", when browsing through the files.  Again,
> I think you are trying to map the existing ISIS file structure onto a NeXus
> file structure with as little modification as possible.  I would prefer it
> if you looked at the current glossary, and tried to see where you would
> store the information the sample blocks contain.  If there is no appropriate
> location, we need to add things to the glossary.
> 
  What are these "sample blocks"?  I write any environment information
  such as temperature into the sample group as is. This will be replaced
  by mean value and stddev in near future (That is how our instrument
  scientists want it).

  If you need to keep a log, I would suggest a NXlog group where you keep
  time stamps and the logged data separatly. These log's are usually only
  used to figure out if the kryostat went mad through the night.  

  If there is a sample changer, then there is a new sample each time and
  you should have a new entry with a new NXsample (and data ) group which
  describes that sample.

  I feel Ray is right, I'am not convinced that we need group arrays.


   Regards,

          Mark