[Nexus] some questions about NXdetector_module

Eugen Wintersberger eugen.wintersberger at desy.de
Wed Jul 1 14:11:00 BST 2015


Hi Mark


> 
> there is another thing to remember: the simple brutal stupid way of
> dealing with arbitrary detectors:
> you give a x_pixel_offset[ndet], y_pixel_offset[ndet] and
> distance[ndet] per detector element with the data becoming data[ndet]
> where ndet is the number of detectors. 

For a total arbitrary detector this is most probably the only way to go.
However, what I meant were detectors where, let's say 20 Pilatus modules
are mounted on an arc.


> 
> 
> Regards,
> 
> 
>     Mark K
> 
> > Am 01.07.2015 um 14:03 schrieb Benjamin Watts
> > <benjamin.watts at psi.ch>: 
> > 
> > Hi Eugen,
> >    I don't use it myself, but I think issue 2 refers to the readout
> > of the detector. The pixels have to be put into some order to be
> > streamed out of the detector and the fast direction would be the
> > lines of pixels that are kept adjacent in the stream. I don't know
> > if this is still needed for non-ancient setups.
> > 
> > Cheers,
> > Ben
> > 
> > On 01/07/15 11:07, Eugen Wintersberger wrote:
> > 
> > > Hi folks 
> > >   I am currently trying to improve the documentation of the `NXdetector`
> > > class. What I am actually trying to do is to compute the spatial
> > > location of a pixel in the laboratory frame for different experiment
> > > configurations. My requirement is that `NXdetector` and
> > > `NXdetector_module` should provide information to do this job. However,
> > > there are some issues we may should think about.
> > > 
> > > issue 1.)
> > > If all transformations involved (in particular `module_offset`) are
> > > required to be translations, we can never deal with curved detectors
> > > which might be very useful. I guess it thus would make sense to replace
> > > `module_offset` my an instance of `NXtransformation`. The best solution
> > > might be to make module_offset an instance of `NXtransformation` rather
> > > than a field?
> > > 
> > > issue 2.) 
> > > What exactly is the content of the `fast_pixel_direction` and
> > > `slow_pixel_direction` field? Are this, for instance, the pixel center
> > > positions along a detector axis?
> > > As an example consider a 1D strip detector with 50um pixel size. Is 
> > > fast_pixel_direction = [0,50,100,150,....] with units = um?
> > > 
> > > issue 3.)
> > > If we want to handle 3D detector as well we maybe should ad a 
> > > `medium_pixel_direction` field ;)
> > > 
> > > If anyone is interested in what I am doing try the issue_412 branch in
> > > the git repository of the Nexus definitions. You find the new text in
> > > the Nexus Design section in the manual.
> > > 
> > > regards 
> > > Eugen
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > NeXus mailing list
> > > NeXus at nexusformat.org
> > > http://lists.nexusformat.org/mailman/listinfo/nexus
> > 
> > 
> > _______________________________________________
> > NeXus mailing list
> > NeXus at nexusformat.org
> > http://lists.nexusformat.org/mailman/listinfo/nexus
> > 
> 
> 
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus

-- 
------------------------------------
DI. Dr. Eugen Wintersberger         
                                    
FS-EC                              
DESY                    
Notkestrasse 85                       
D-22607 Hamburg                    
Germany                            
                                   
E-Mail: eugen.wintersberger at desy.de
Telefon: +49-40-8998-1917          
-----------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.nexusformat.org/pipermail/nexus/attachments/20150701/859636e3/attachment.sig>


More information about the NeXus mailing list