AD: write HDF5 files using Single mode

[prjemian]

The USAXS is used to collecting area detector images in SPEC with a configuration as shown in the following screen view:

[prjemian]

This might need some customizations for ophyd.areadetector.filestore_mixins.FileStoreHDF5IterativeWrite to configure the staging properly and not include the det.hdf1.capture signal. Also need to ensure point_number is written properly for databroker to retrieve the image from the HDF5 file.

[prjemian]

Implementation here should consider #671. The NSLS-II area detector support has some changes. Here, new version-specific mixins would be appropriate.

[prjemian]

TIL:

class FileStoreHDF5SingleIterativeWrite(FileStoreHDF5Single,
                                        FileStoreIterativeWrite):
    '''
    Used for running Areadetectors hdf5 plugin in `Single` mode, with
    `point_number` in the kwargs.
    '''
    pass

with point_number in the kwargs

is the sole reason for FileStoreIterativeWrite. Wow, that documentation is so impotent at describing this basic step. And the FileStoreIterativeWrite class name should be AddPointNumber or some such. This is a classic example why ophyd's AD support is difficult to master and modify.

[prjemian]

Also, in conversation on Slack:

FileStoreHDF5SingleIterativeWrite sets filestore_spec = "AD_HDF5_SINGLE" which ends with an Exception from dask that the index must be an intenger, not a tuple. In this case the index value was found to be (None, slice(None, None, None), slice(None, None, None), slice(None, None, None))).

As @tacaswell replied on (Slack):

I am 75% sure that is a bug in the handler
...
that handler does not conform to what we expect handlers to do (return an ND sliceable thing)

The handler for the filestore_spec = "AD_HDF5_SINGLE", that is.

[prjemian]

Let's review:

• FileStoreHDF5IterativeWrite is the class for most AD+HDF5 work
• FileStoreHDF5SingleIterativeWrite was for a special case

Andrew Walters (NSLS-II) replied on Slack:

[The AD_HDF5_SINGLE handler] was written for a specific detector that wrote out a HDF5 file (or perhaps files) with a strange format.

[prjemian]

So, we'll need a new mixin class to accomplish what we want. Here are the goals for that class:

• Configure AD HDFwriter plugin (by a mixin class) to acquire a set of frames into one HDF5 file.
• Write file specifications such that the AD_HDF5 specification may be used.
• One push of det.cam.acquire for the frame set.
• No push of det.hdf1.capture is needed, so it should not be staged either.
• Other configuration as shown in above screen view.

[prjemian]

There is a repair pending for AD_HDF5_SINGLE handler:

• AD_HDF5_SINGLE: return sliceable object bluesky/area-detector-handlers#32

[prjemian]

For the AD_HDF5 filespec, acquiring 5 frames into a single HDF5 file, an example of run.primary._resources:

In [16]: run.primary._resources
Out[16]: 
[Resource({'path_semantics': 'posix',
 'resource_kwargs': {'frame_per_point': 5},
 'resource_path': 'tmp/docker_ioc/iocad/tmp/example/2022/09/30/0b6359e3-7ae1-433f-a086_000000.h5',
 'root': '/',
 'run_start': 'b8feb932-3644-4328-8534-0bf088281035',
 'spec': 'AD_HDF5',
 'uid': '7261c07c-63c8-437c-ab6e-98e0b8e814a3'})]

[prjemian]

For AD_HDF5_SINGLE, acquiring 5 frames, into 5 separate HDF5 files:

In [16]: run.primary._resources
Out[16]: 
[Resource({'path_semantics': 'posix',
 'resource_kwargs': {'filename': '90193be9-1ec1-4cb5-92e1',
                     'frame_per_point': 5,
                     'template': '%s%s_%6.6d.h5'},
 'resource_path': 'tmp/docker_ioc/iocad/tmp/example/2022/09/30',
 'root': '/',
 'run_start': 'a8a2cd85-212f-441e-b6c2-17e1a7cd70f5',
 'spec': 'AD_HDF5_SINGLE',
 'uid': '764374aa-5059-4ff1-b33f-9d17f76ebfa9'})]