[NeXus-tech] For possible discussion in the hangout today
Herbert J. Bernstein
yayahjb at gmail.com
Wed Jun 4 05:35:01 BST 2014
To: Interested Parties
From: H. J. Bernstein
Re: Open issues for NeXus handling of multi-module detectors
There are some issues that need to be resolved to finish the definitions
for the handling of the Eiger, FEL, Pilatus 12M-DLS and other multi-
module detectors:
1. The handling of the data itself;
2. The association of axes with the data;
3. The handling of array sections or regions of interest.
1. The handling of the data itself.
The current Dectris Eiger specification is for several data arrays, each if
which will contain a significant number of images. There are multiple
modules
per detector, but the current plan is to treat the images as if they
came from
one large panel. Dectris has proposed having several NXData groups with
names
data_xxxxxx, but each would actually be a link to an external file
data:NXdata
group. Each array consists of a number of complete images drawn from
multiple
modules. The compression logic uses one chunk per image. A single scan is
likely to involve multiple arrays. The Dectris design assumes a master
file with most of the metadata an a significant number of external files
with the
actual data. For the largest Eigers, there would probably be about 50
images per
data block. For smaller Eigers there could be several hundred to a few
thousand
images per data block.
Because of the use of multiple data blocks in the Eiger, the usual practice
of also having the data in the NXdetector group connected to the data in
NXdata by links will not work, because the field name data will be repeated,
or non-conforming field names will be needed.
The CSPAD proposal from Aaron Brewster proposal is for several master
files,
one per, run, with the metadata for metrology of the detector, linked to
multiple
external files with the actual data, the wavelength for each image and
a timestamp for each image. There are 64 ASICs in the CSPAD, so for
each run there would be some numtiple of 64 data blocks organized by
ASIC x,y
and frame number, organized with about 50 -- 500 images per data block.
The Pilatus 12M-DLS with produce images from a cylinder of detector modules,
organized into 24 rows of 5 modules per row. The entire image will be read
out as if coming from one large panel, but it is important to have access
to each row (if not each module) separately.
2. Association of axes with the data.
For these detectors, it is essential to be able to associate each pixel
with its
position in space. To get this information, we need both information
about the
positions of pixels relative to the detector and about the position of
the detector in space.
For the Eiger, even though detail module positioning information is
available,
the entire detractor is treated as if it were a uniform array of pixels,
so an only two axes for the two orthogonal edges of the detector are needed.
For the CSPAD, it is essential to determine positions on a finer grain,
so many more axes are needed. For the Pilatus-12M-DLS at a minima,
each of the
24 rows needs two axes.
3. The handling of array sections or regions of interest.
For the Pilatus-12M-DLS, the data from each planar row will be contained
within a larger
array of 12 megapixels. Tobias Richter has suggested similar
aggregation for the CSPAD
and use os something similar to the Dectris region_of_interest field to
associate axis
information with a portion of an array.
The proposed solution:
We propose the following approach to implement the above requirements:
A. Inclusion of an arbitrary number of NXdata groups with different
names in NXentry,
NXDectector or other groups, with some instance of the data being
present in its
enclosing group and the other instances being linked to that primary
instance. This
would be a change in the NXdetector base class definition, but is
preferable not being able
to freely associate the data with its metadata, and has already been
accepted by NIAC
in the Dectris specification for inclusion in NXentry. We will discuss
the reasons
to allow this in other groups below.
B. For the CSPAD, we propose a structure similar to that for the Eiger,
with
all the metrology data gathered under
NXinstrument/NXtransformations
and
NXinstrument/NXdetector/NXtransformations
Master file:
* entry:NXentry
/ELE_D0Q0S0A0 -> <subfile_name>/entry/ELE_D0Q0S0A0
/ELE_D0Q0S0A1 -> <subfile_name>/entry/ELE_D0Q0S0A1
...
/instrument:NXinstrument
/transformations:NXtransformations
/AXIS_SOURCE
@transformation_type="general"
@equipment_component="source"
@depends_on="."
@vector=[0,0,-1]
/AXIS_GRAVITY
@transformation_type="general"
@equipment_component="gravity"
@depends_on="."
@vector=[0,-1,0]
+ CSPAD_FRONT:NXdetector
/transformations:NXtransformations
/AXIS_D0_Z
@transformation_type="translation"
@equipment_component="detector_arm"
@depends_on="."
@vector=[0,0,-1]
/AXIS_D0_Y
@transformation_type="translation"
@equipment_component="detector_arm"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/AXIS_D0_Z"
@vector=[0,1,0]
/AXIS_D0_X
@transformation_type="translation"
@equipment_component="detector_arm"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/AXIS_D0_Y
@vector=[-1,0,0]
/AXIS_D0_R
@transformation_type="rotation"
@equipment_component="detector_arm"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/AXIS_D0_X"
@vector=[0,0,-1]
@offset=[0,0,0]
@offset_units="mm"
/FS_D0Q0
@transformation_type="rotation"
@equipment_component="detector_quadrant"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/AXIS_D0_R"
@vector=[0,0-1]
@offset=[49.6,43.6,0.01203125]
@offset_units="mm"
/FS_D0Q0S0
@transformation_type="rotation"
@equipment_component="detector_sensor"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/FS_D0Q0"
@vector=[0.000974376302058 0.00044773585801
-0.999999425062]
@offset=[-11.304125,-23.19540625,-0.00753125]
@offset_units="mm"
/FS_D0Q0S0A0
@transformation_type="rotation"
@equipment_component="detector_asic"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/FS_D0Q0S0"
@vector=[0,0,-1]
@offset=[10.835,0.0,0.0]
@offset_units="mm"
/AXIS_D0Q0S0A0_S
@transformation_type="translation"
@equipment_component="detector_asic"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/FS_D0Q0S0A0"
@vector=[0,-1,0]
@offset=[10.670000 10.175000 0.0]
@offset_units="mm"
/AXIS_D0Q0S0A0_F
@transformation_type="translation"
@equipment_component="detector_asic"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/AXIS_D0Q0S0A0_S"
@vector=[-1,0,0]
@offset=[0,0,0]
@offset_units="mm"
/FS_D0Q0S0A1
@transformation_type="rotation"
@equipment_component="detector_asic"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/FS_D0Q0S0"
@vector=[0,0,1]
@offset=[-10.835 0.0 0.0]
@offset_units="mm"
/AXIS_D0Q0S0A1_S
@transformation_type="translation"
@equipment_component="detector_asic"
@depends_on="/entry/instrument/CSPAD_FRONT/transformations/FS_D0Q0S0A1"
@vector=[0,-1,0]
@offset=[10.670000,10.175000,0.0]
@offset_units="mm"
...
# ELE_D0Q0S0A0:NXdectector_module
/data->/entry/ELE_D0Q0S0A0
# ELE_D0Q0S0A1:NXdectector_module
/data->/entry/ELE_D0Q0S0A1
# ELE_D0Q0S1A0:NXdectector_module
/data->/entry/ELE_D0Q0S1A0
# ELE_D0Q0S1A1:NXdectector_module
/data->/entry/ELE_D0Q0S1A1
... for 64 elements
Sub-files:
/entry/NXentry
/ELE_D0Q0S0A0:NXdata
/data=[...]
@axes="FRAME:AXIS_D0Q0S0A0_S:AXIS_D0Q0S0A0_F"
links for the actual axes back to the master file
/ELE_D0Q0S0A1:NXdata
/data=[...]
@axes="FRAME:AXIS_D0Q0S0A1_S:AXIS_D0Q0S0A1_F"
links for the actual axes back to the master file
links for the actual axes back to the master file
...
/sample:NXsample
/beam:NXbeam
/wavelength=[...]
C. For the Pilatus 12M-DLS, we need to identify segments of arrays and
handle them
similarly to the detector module data in case B. We propose to allow
nesting
NXdata within NXdata to instead of having
/data=[...] with associated axes
we can a master data:NXdata, and for a given row, say, ROW_6 have
/ROW_6:NXdata
data->/entry/data
/array_segment_low=[ ... ]
/array_segment_high=[ ... ]
where the array segment consists of upper and lower bounds of the
indices to be considered
as part of the data in ROW_6
More information about the NeXus-tech
mailing list