[Nexus] DECTRIS again

Wintersberger, Eugen eugen.wintersberger at desy.de
Wed Oct 24 13:48:18 BST 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Nobody at the telecon today - only me and Pete?

On 10/24/2012 01:35 PM, Mark Koennecke wrote:
> Tobias,
> 
> On 10/24/2012 12:55 PM, Tobias.Richter at diamond.ac.uk wrote:
>> 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.
> Really? We have done so before.
>> 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.
> So, how do you wish to proceed then?
>> Anyway we should not manoeuvre us into a position were we
>> replace votes or community agreement by deadlines.
> This was never my intention. I brought the topic up for discussion
> as soon as I became aware of it.
> 
> Regards,
> 
> Mark
>> 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
>> 
> 
> _______________________________________________ NeXus mailing list 
> NeXus at nexusformat.org 
> http://lists.nexusformat.org/mailman/listinfo/nexus


- -- 
- ---------------------------------------
| DI. Dr. Eugen Wintersberger         |
|                                     |
| FS-EC                               |
| HASYLAB at DESY                     |
| Notkestr. 85                        |
| D-22607 Hamburg                     |
| Germany                             |
|                                     |
| E-Mail: eugen.wintersberger at desy.de |
| Telefon: +49-40-8998-1917           |
- ---------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iF4EAREIAAYFAlCH45IACgkQlIP0H82W0vBlVwD/UqOn2YbY+m//MjefjozsGBXu
k8LNaPiKUUuMyw+XlQsA/0YWqXACitjjEP/AkHjMbiD4gLetRvDc+2iQ5O9eoPJe
=57oG
-----END PGP SIGNATURE-----



More information about the NeXus mailing list