[Nexus] some questions about NXdetector_module

[Tobias Richter]

Hi Eugen,

> On 1 Jul 2015, at 11:07, Eugen Wintersberger <eugen.wintersberger at desy.de> wrote:
> 
> 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?

The aim of NXdetector_module was to simplify the relatively common case 
of several flat detector modules with a common readout system.
For the completely general case there are x_pixel_offset and y_pixel_offset 
(no z_pixel_offset yet) to allow for an arbitrary arrangement of pixels.
This may need a review if it is still functional with the current geometry model
and at least an added third dimension. 
If curved detectors have a set of common requirements we are not addressing 
correctly we can discuss that. My guess would be that they all have slightly 
different ways of curving etc so the general case may work fine.

Keep in mind: The module_offset is a proper transformation, so you can have 
as many transformations between the module and the origin of the detector via
the depends_on attribute. You are free to store that in NXtransformation obviously.

> 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?

If I remember correctly the idea was that this would be the pitch if one value
and as you describe with a 1d array. Which ones of these are actually supported
at the moment, I am not sure. 

> issue 3.)
> If we want to handle 3D detector as well we maybe should ad a 
> `medium_pixel_direction` field ;)

Annoyingly that is something I will have to worry about. I’m not sure I like your 
name, mainly because I am not sure I would want to sandwich z into x and y.
The defaults assumption with fast/slow should still give you a not too strange
image, if possible.

> 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.

In your detector.txt you assume that all 2d detector measure “area”.
Not all detectors do imaging in the widest sense. There are those that record 
angle vs energy. Or space vs wavelength.
Nice to have images as well! I have not checked them for correctness yet.

Regards,

Tobias