[Nexus] DECTRIS again

Mark Koennecke Mark.Koennecke at psi.ch
Thu Oct 4 13:38:45 BST 2012


Hi,

there are still some open points about the DECTRIS detector which have 
come up.

First the time issue: I got better documentation what the times actually 
mean:

frame_time = exposure_time + detector_readout_time
frame_time:    time at which data is sent to readout-computer, i.e. 
defines the speed of the data collection or the
                         speed and can be put on the same level as 
exposure time for an integrating detector
                         (like a CCD, Imaging Plate,...)
exposure_time:    time during which detector counts X-rays
detector_readout_time:  time the detector takes for a complete readout 
of all chips, i.e. defines the minimum time after
                                         which the detector can count again

With this explanation, are we now happy with the names?

And a new issue came up: detector modules. The EIGER detector consists 
of various modules
which are arranged to build the full detector. There are gaps between 
the modules.  The
EIGER SW calculates a combined image from the contributions of the 
modules. In the case
of a flat detector the DA SW looks at the mask to find out about gaps. 
Happiness al around.

But the modules may be arranged along an arbitrary form, may be half 
sphere. The detector
SW will still recombine the modules to an image, just for the user to 
look at it. But then the DA
SW needs the position and orientation of the individual modules. And an 
indication at which
indices the module starts in the combined image. The question is now how 
to describe those
modules. As the DA may need it, this is no longer DECTRIS private but 
should be addressed by us.

The first option would be to have NXgeometries in NXdetector:

NXdetector
      module01,NXgeometry
               NXtranslation
               NXorientation

     module02,NXgeometry
              NXtranslation
              NXorientation

    .....
This option is missing the index information. I am not sure if we want 
to add that to NXgeometry. I am
also not sure if we still wish to advocate the use of NXgeometry. IMHO, 
the CIF mapping is better
and NXgeometry may be deprecated soon.. But is not yet....

The second option would be a new group: NXdetector_module looking like this:

NXdetector
          module01,NXdetector_module
                  x[nx]
                     @offset=...
                     @vector= ...
                  y[ny]
                     @offset=...
                     @vector=....
                 x_data_offset
                 y_data_offset
The x any y arrays describe the pixels of the module, the offset and 
vector attributes the position and
orientation in space. The indices go into the x,y_data_offset.

Of course there are other options......

What do you think? We should reach an agreement at the next telco latest.

Best Regards,

                 Mark Koennecke









More information about the NeXus mailing list