Scans involving 2D detectors

This section brings together those pieces of information which are relevant when executing scans involving 2D detectors.

The procedure to perform a 2D detector scan:

• Prepare the measurement group as described in 4.4, e.g.:

  spock> change_mg -g mg1 -t exp_t01 -c exp_c01,exp_petra -m exp_mca01 -q pilatus
  

• Set the FileDir attribute of the Tango server. The value has to be compliant with rootDir, see below.

• Set the FilePostfix attribute of the Tango server, e.g. to .cbf

• Prepare a pre-scan general hook to store the images in the standard directory structure, see 14.2.3. The images belonging to a scan will be stored in a directory named

  <rootDir>/<scanName>/<detectorName>, e.g. /ramdisk/au_00007/pilatus
  

  Make sure the hook is enabled:

  spock> gh_enable
  

  The hook has an internal variable named rootDir representing the root path of the 2D data storage. The fact that the image path is controlled from two places, the Tango server (FileDir) and the hook (rootDir), violates the principle that such information should be stored in one place only. However, this situation cannot be avoided because the user may have set FileDir for some other purpose and the hook cannot derive the rootDir be reading FileDir because this string may have some complicated structure. To cope with this nasty situation, the hook compares rootDir and FileDir and throws a exception, if FileDir does not begin with rootDir. This way a safe operation is assured.

• Since NeXus is still quite new at our beamlines, we recommend to produce the NeXus file in parallel with e.g. .fio output. This can be done with nxselector or by

  spock> senv ScanFile "['sampleName.fio', 'sampleName.nxs']"
  

• Let's assume that
  • ActiveMntGrp consists of exp_t01 exp_t01, exp_mca01, exp_c01, exp_petra, pilatus
  • rootDir is /ramdisk
  • ScanFile is "['sampleName.fio', 'sampleName.nxs']"
  • ScanDir is /gpfs/current/raw.

  After the scan we find these files:

  pilatusPC:/ramdisk/sampleName_00001/pilatus/sampleName_00001_00001.cbf
                                              sampleName_00001_00002.cbf
                                              ...
  /gpf/current/raw/sampleName_00001.fio
  /gpf/current/raw/sampleName_00001.nxs
  /gpf/current/raw/sampleName_00001/sampleName_00001_mca_s1.fio
                                    sampleName_00001_mca_s2.fio
                                    ...
  

  Using one way or another the cbf files will be moved into the GPFS, e.g.:

  $ cd /gpfs/current/raw
  $ scp -r pilatusPC:/ramddisk/* ./
  

  Which gives us:

  /gpf/current/raw/sampleName_00001.fio
  /gpf/current/raw/sampleName_00001.nxs
  /gpf/current/raw/sampleName_00001/sampleName_00001_mca_s1.fio
                                    sampleName_00001_mca_s2.fio
                                    ...
  /gpfs/current/raw/sampleName_00001/pilatus/sampleName_00001_00001.cbf
                                             sampleName_00001_00002.cbf
                                             ...
  

  Notice that the NeXus file contains 0D and 1D data, not the .cbf files.

• At this point the user has several options how to proceed.
  • Collect the images. The command

    $ nxscollect execute /gpfs/current/raw/sampleName_00001.nxs
    

    inserts the cbf images into the NeXus file making it complete in the sense that all data measured during a scan is contained in a single file decorated by annotations.

    Pros: all data are stored in a single file, HDF5-aware applications can access the data.

    Cons: measurements may generate data too big to be stored in a single file, certain analysis application may need tif or cbf input requiring an extra conversion step.

  • Create external links. A tool will be installed which converts the cbf files into NeXus files, one file per images. The tool will also create the corresponding links in the master NeXus file.

    Pros: the Lambda server creates NeXus ouput anyway, NeXus-aware applications to access data in a transparent way.

    Cons: scan data is scattered in many files.

  • Nop.

    Pros: cbf and tif applications can access the data directly.

    Cons: scan data is scattered in many files, HDF5-aware applications require a conversion step.

  Future will tell which way is best to organize scan data.