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:
spock> change_mg -g mg1 -t exp_t01 -c exp_c01,exp_petra -m exp_mca01 -q pilatus
<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.
spock> senv ScanFile "['sampleName.fio', 'sampleName.nxs']"
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.
$ nxscollect append /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.
Pros: the Lambda server creates NeXus output anyway, NeXus-aware applications to access data in a transparent way.
Cons: scan data is scattered in many files.
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.