[Nexus] some questions about NXdetector_module

[Tobias Richter]

> 
> On 1 Jul 2015, at 14:13, Eugen Wintersberger <eugen.wintersberger at desy.de> wrote:
>>> 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.
> 
> I think the best way to deal with this would be to add a
> `fastest_pixel_direction` field. I made some updates on the branch where
> I think provide a solution for how to deal with the different
> dimensions. 

That is may as good as it can get. It does imply that the fastest dimensions 
are always of spatial nature. Below I am arguing that there can of other properties
(like energy or wavelength or time delay) recorded along those. 

>> 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.
> 
> My interpretation of the `layout` field is that it just says how the
> sensitive region of the detector looks. A 0D detector is a `point` (ok,
> one can argue now that all theses detectors have naturally an area). 
> `linear` is a strip and `area` is a 2D surface. 

My point is that there is no general mapping between the dimensions 
of the data and the lab coordinate system or sensor area. You can have an 
energy dispersive point detector recording to 1D. Add stroboscopic time bins
and you’re at 2D from a single pixel.

That’s in the beginning of your "working with detectors” file. You also 
suggest that anything we don’t have a layout enum for is not supported.
While “layout" is a field we define, things don’t stop working when it does 
not apply.

Regards,

Tobias