[Nexus] DECTRIS again
Tobias.Richter at diamond.ac.uk
Tobias.Richter at diamond.ac.uk
Wed Oct 24 11:55:48 BST 2012
Hi Mark,
I am concerned that we lose track of out primary objectives. Your reply seems to suggest we can work on different time scales for adding Dectris definitions and making sure files can be reliably understood on the other hand. This is exactly my point, we can not.
NeXus as a format that does not allow to reliably retrieve the geometry is of no use to us. The fact that this hasn't been possible for the last 16 years is nothing I would start advertising. Things have moved on and people are taking up NeXus on the promise it delivers value and people do start writing the code that we have been waiting for the last 16 years. But my impression is that we still approach the problem too much from the writing side.
To serve users and Dectris alike we need to develop the format with care and create something that works well for everyone in the future. NeXus allows Dectris to put in whatever they like as additional information, but they probably want our input for a reason.
Anyway we should not manoeuvre us into a position were we replace votes or community agreement by deadlines.
Regards,
Tobias
Disclosure: I work for the (to my knowledge) largest Dectris customer.
________________________________________
From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on behalf of Mark Koennecke [Mark.Koennecke at psi.ch]
Sent: 24 October 2012 11:05
To: Discussion forum for the NeXus data format
Subject: Re: [Nexus] DECTRIS again
Tobias,
On 10/23/2012 05:36 PM, Tobias.Richter at diamond.ac.uk wrote:
> My argument is wasn't against accommodating Dectris. But if we do offer fast track service strictly speaking (outside of the current constitution) to some the conditions should be clear and not subjective.
There may be a misunderstanding here... But I got the impression that
the NIAC endorses this DECTRIS
project. This is why I am trying to go fast. This is why I do not think
this is subjective. But may be it is
necessary at NIAC meetings not only to decide what is going to be done
but also with which priority.
> The other issue about the geometry was targeted at programs written for reading the existing non-modular detectors. They would not look for the module information. There should some information missing in order for them not to silently assume the wrong geometry. Then the user is aware and will spot the module when investigating.
Is this asking for a means to figure out what kind of detector we are
dealing with? If so,
I agree, this needs to be added in some point. The question is: do we do
this now or when
we have made up our minds about OO-NeXus which can take 2 years? Thing
is, we got
away without having that for 16 years.
Regards,
Mark
>
> Regards,
>
> Tobias
>
> ________________________________________
> From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on behalf of Mark Koennecke [Mark.Koennecke at psi.ch]
> Sent: 23 October 2012 14:58
> To: Discussion forum for the NeXus data format
> Subject: Re: [Nexus] DECTRIS again
>
> Hi all,
>
>
> On 10/22/2012 03:59 PM, Tobias.Richter at diamond.ac.uk wrote:
>> Hi all,
>>
>> I did recall us deciding something for the exposure_time, but at least it wasn't known to all in this mailing list.
>>
>> The scheme would work with something like this:
>>
>> detector:NXdetector
>> data[j,k,l] = [....]
>> detector_arm[1] = [250]
>> @transformation=translation
>> @vector={1,0,0}
>> @units=cm
>> @depends_on=/entry/instrument/something/brick
>> depends_on=detector_arm
>> module:NXdetector_module
>> data_origin[2] = [l,m]
>> data_size[2] = [n,o]
>> module_offset[1] = [250]
>> @transformation=translation
>> @vector={0,1,1}
>> @units=mm
>> @depends_on="../detector_arm"
>> fast_pixel_direction[1] = [0.172]
>> @transformation=translation
>> @vector={1,0,0}
>> @units=mm
>> @depends_on="module_offset"
>> slow_pixel_direction[1] = [0.172]
>> @transformation=translation
>> @vector={0,1,0}
>> @units=mm
>> @depends_on="module_offset"
>> module:NXdetector_module
>> ....
>>
>> This is just a (hopefully) complete illustration to show what we need to specify. I am more than happy for suggestions to modify this.
> This is another version of what I have suggested, but has the advantage
> that we do not need
> x and y arrays. I can live with this, all necessary data is specified.
> As was with my suggestions.
> Just wasting some more space....
>
>> We would also need to make sure that interpreting the detector in the traditional way fails. Otherwise software will pick up the wrong geometry.
> Please elaborate.
>> I am not sure why we are in such a rush, though. They are not about to ship a detector like that in the next days, are they? We can put something like the above in front of them and say that is vaguely what it will contain. But we will need to put some thought into it. In the end the way we currently use the Pilatus that information would be written by me anyway as I have no intention updating the detector on its geometry all the time.
> The thing is that DECTRIS wishes to call two meetings pretty soon and
> until then the thing
> should be ready. And early, such that they can prepare example files,
> reading code etc...
>
> The first of this meeting, with DA analysis SW people will already by
> end of november. As
> DECTRIS pays for it, it is s a closed meeting.
>
> The second, with a larger audience including those of you who want,
> will be in January.
>
> This is why I try to rush this. Waiting for the next code camp or NIAC
> meeting will not do.
>> Bottom line is: It should not be too obvious that institutions actually devoting manpower towards NeXus do not receive the same fast-track service for their requirements.
> Well, I think this DECTRIS thing is important to get NeXus through the
> door of many facilities.
> IMHO a little exertion on our side is justified.
>
>
> Regards,
>
> Mark
>> Regards,
>>
>> Tobias
>>
>> ________________________________________
>> From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on behalf of Mark Koennecke [Mark.Koennecke at psi.ch]
>> Sent: 19 October 2012 16:25
>> To: Discussion forum for the NeXus data format
>> Subject: Re: [Nexus] DECTRIS again
>>
>> Tobias, Pete,
>>
>>
>> On 10/18/2012 05:06 PM, Tobias.Richter at diamond.ac.uk wrote:
>>> Hi,
>>>
>>> I'm with Ben on the critique of the "exposure_time".
>> I was of the impression that we decided on the last Telco to make them
>> use count_time.
>> This is what I forwarded to them.
>>
>>> For the modules one problem is that the "data" will be one big image array. So we need to identify the module slice with something [x,y,dx,dy]. This would apply to the last slicerank/2 dimensions of the dataset (in case of scans).
>>>
>>> With that if you have one displaced module were this in the data:
>>>
>>> +--------------+
>>> | |
>>> | |
>>> | |
>>> | +----+
>>> | | |
>>> +---------+----+
>>>
>>> Is actually like this in real space:
>>>
>>> +--------------+ +----+
>>> | | | |
>>> | | +----+
>>> | |
>>> | +----+
>>> | |
>>> +---------+
>>>
>>>
>>> You would need to describe that as at least three modules unless we make the scheme more complex.
>>>
>>> For the elements the (simplified) CIF standard uses
>>> * an origin relative to the nominal detector position
>>> * a fast vector with pixel displacement along it
>>> * a slow vector with pixel displacement along it
>>> The detector normal is in the direction of the cross product of the two vectors.
>>> There are more complicated schemes for non-regular/rectangular, e.g. hexagonal pixels. I'd suggest we deal with those as and when required.
>> Can you please give an example of a NXdetector_element group with this?
>> I agree that having those
>> arrays is a tad overkill.
>>
>> Concerning Pete's reply:
>>
>> yes, NXdetector is the class which would benefit the most if we take
>> apart NeXus to become
>> more OO-oriented. IMHO, in NXdetector there are two opposing forces:
>>
>> - We already have a means to describe each detector pixel individually.
>> This is the most general
>> case. But this is cumbersome.
>> - We wish to maintain the spatiality of the detector in order to give
>> the user what she expects: if she
>> has an area detector, she should see that on file. And not a
>> description of each pixel.
>>
>> When entering the realm of OO-NeXus I am now starting to think more of
>> interfaces. OO does not match so
>> well anyway. And I have reservation against a more complicated hierarchy
>> anyway.
>> The interface approach would mean: You start with a plain NXdetector, if
>> you a 2D you add these fields,
>> if you have TOF do this, if you have 2D and TOF do this, etc.
>>
>> So, I think we could go quick with a solution to the problem: if you
>> have a patched together detector
>> do this. I do wish to give DECTRIS a timely answer on this. May be
>> modelled on CIFS approach.
>>
>> Have a nice weekend,
>>
>> Mark
>>
>>
>>> I am not sure how this translates into your second option, Mark.
>>> If we assume the pizels are all evenly spaced, I think we do not need the arrays for the positions, though.
>>>
>>> Comments?
>>>
>>> Tobias
>>>
>>> ________________________________________
>>> From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on behalf of Watts Benjamin [Benjamin.Watts at psi.ch]
>>> Sent: 04 October 2012 15:07
>>> To: Discussion forum for the NeXus data format
>>> Subject: Re: [Nexus] DECTRIS again
>>>
>>> Hi,
>>> I'm happy with all the names except that "exposure_time", which is
>>> clearly used in contradiction to the meaning of the word "exposure" and
>>> the nature of the hardware. (Only a light source or shutter would
>>> control an actual exposure time.) If a new field is required, then I
>>> would prefer it be named "accumulation_time". However, the field
>>> "count_time" already exists in NXdetector and would suit the purposes of
>>> DECTRIS perfectly well. My reccommendation therefore is that DECTRIS use
>>> "count_time" instead of making a new "exposure_time" field.
>>>
>>> For describing the positions of the detector modules, I vote for the
>>> CIF-like option since forward-compatibility is more of an issue than
>>> backwards-compatibility in this case.
>>>
>>> Cheers,
>>> Ben
>>>
>>>
>>> -----Original Message-----
>>> From: nexus-bounces at nexusformat.org
>>> [mailto:nexus-bounces at nexusformat.org] On Behalf Of Mark Koennecke
>>> Sent: Donnerstag, 4. Oktober 2012 14:39
>>> To: Discussion forum for the NeXus data format
>>> Subject: [Nexus] DECTRIS again
>>>
>>> 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
>>>
>>>
>> _______________________________________________
>> 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
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
More information about the NeXus
mailing list