NeXus-5

[Mark Koennecke]

  High,
  
  The new NeXus-API version which supports HDF5 is in its final stages and
  will probably be released in the next few weeks. It was definitly worth
  the effort as the HDF5 API has its own set of quirks and inconsistencies.
  Unfortunately a few API changes will be required:
  
  For HDF5 the data compression must be specified at data set creation
  time. This implies that our current scheme with the call sequence
  NXmakedata followed by NXcompress will not work. Instead we suggest:
    a) a new API function:
      NXstatus NXcompmakedata(NXhandle h, char *name, int type, int rank,
                              int iDim[], int comp_typ, int bufSize)
      for creating compressed data sets. The old NXmakedata will be 
      kept for compatibility but will call NXcompmakedate with 
      compression set to none. The last parameter >bufSize< determines the
      chunking of the compressed dataset. This has a large impact on
      HDF5 compression performance. 
    b) NXcompress should be marked as deprecated and will continue to
       work for HDF4 but calling it for HDF5 will cause an error.
  
  For existing files the API can figure out if it is a HDF4 or a HDF5 file
  and act accordingly. However when creating a file the user must specify 
  what he wants. We suggest the following scheme:
  - NXopen with NXACC_CREATE will create a HDF4 file.
  - NXopen with NXACC_CREATE5  will create a HDF5 file. 
  
  One problem could be solved without a API change: HDF5 does not  support
  the concept of vGroup classes. We solved this by storing a group attribute
  with the name nxclass which holds the NeXus class name. 
  
  Another HDF5 limitation is that groups are listed in alphabetical order,
  not in the order of creation as with HDF4. Until now we relied on 
  listing order in order to determine in which sequence the components
  of an instrument occur. The HDF5 people think that they will fix this
  in some stage but when this will be is unknown. If we agree to give
  instrument positions in McStas coordinates it would not matter anyway.
  
  
  Any comments on this?
  
      Regards
      
             Uwe Filges
	     Mark Koennecke