[Nexus] Desire for a more rigorous NeXus standard

[Mark Koennecke]

  High there,

  here are a couple of comments on Tom Kozlowski's NeXus File Specification 
  Issues. Perhaps it is also useful to define two different scopes of 
  standards: A general part which describes the structure and names which
  could be used. And a instrument definition which goes into far more detail
  concerning appropriate names at a certain type of instrument, units etc.
  Some of Tom's points result from this not being properly separated now.

  My comments are ordered as the sections in Tom's document.


  General 1.1.7. suggested SDS attribute data_name. For groups there is both
  the name and the NeXus class. This comes from an object oriented view where
  a class (the NeXus class) can have several instances. A SDS however is a
  simple field and should be fully qualified just by its name. I think the
  data_name attribute adds some unneeded complexity.

  General 1.1.8 HDF-links. Yes, a dataset or group can always be replaced 
  by a link in order to avoid data duplication. But do not link if the data
  changes!

  General 1.1.9 Standard coordinate system. With the group order so badly
  preserved in HDF-5 this is an issue. In some stage I remember an 
  agreement to use the same coordinate system as McStas. Is this still
  acceptable?

  General 1.1.10 Units. These days one has to recommend  SI units.

  NeXus File Structure 2.1.1 multiple users, Is this really an issue? It is
  difficult to get users to fill in this information anyway.  Moreover
  user information is administrative and usually not needed for data analysis.
  Perhaps keep in a private group.

  2.1.2 The file level attributes are mandatory, to my knowledge.

  2.1.3 No restrictions at file level. 
  - It is not necessary to put common groups at root level. You can as 
    easily link against groups under the first NXentry in subsequent 
    NXentries as linking against common groups at root level.
  - It was defined that the NeXus part begins with an instance of NXentry.
    Users are free to add whatever they want to the HDF file. It just isn't
    NeXus anymore. 

  3. NXentry

  3.1.2 standard NXentry name. Tom suggested a naming scheme  based on run 
  numbers. I have a conflict with that at my four circle where one run 
  consists of multiple frames which are stored in a NXentry each.

  3.1.4 Notes Is this of such general interest that we have to standardize it?
  Or can this be left to local extensions?

  4. NXdata My view on the usage as I understand it:
  - a NXdata group should contain the dataa necessary to do a quick plot.
    * This is some data element with the attribute signal=1
    * some SDS describing the axis of the main dataset, each with a axis=1, 
      axis=2, etc.. attribute in order to sort the axis.
    * If you desire an error dataset as well.
  - If there are multiple detector banks there must be a NXdata group for
    each detector bank.

   4.1.4 category attributes. In Tom's suggested usage this would be 
   diagnostics. As diagnostics are detector and instrument specific this may
   be beyond the scope of NeXus and a good case for a local group. 

   5. NXlog Yes, any variable should be loggable. 

   7.  NXsample
   - The standard currently gives names for what could be there. Not all
     variable need to be used at a given instrument. Just what is needed. 
     The exact names needed are in the scope of an instrument definition.  
   
  8. NXmonitor I feel that we should keep monitors and detector apart.
     It feels clearer to me if I can find the interesting data in a NXdetector
     group and not find a monitor useful for scaling only there. 

     I think it is a good idea to include the monitor position 
     (in McStas units?) and dimensions. 
  

     Units should be SI.

    9. NXinstrument unnecessary?
       This could be argued about. I also think it would be more consistent
       to inline NXsample and Nmonitor into NXinstrument. 

    10. NXsource Again the scope of an instrument definition is touched.
    11. NXdetector Again the scope of an instrument definition is touched.

    12. NXchopper If you have a measured energy, use that! Also I want to
    add a tilt angle for velocity selectors.

    13. NXcrystal. NXcrystal may be a misleading name, this is really a 
    single crystal monochromator. 

    I'am sure that I'am not the only one with comments.

	      Best Regards,

			Mark Koennecke