[Nexus] DECTRIS again

Wintersberger, Eugen eugen.wintersberger at desy.de
Wed Oct 24 09:05:56 BST 2012


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

I actually work on such code ;)

Eugen

On 10/23/2012 06:13 PM, Tobias.Richter at diamond.ac.uk wrote:
> In principle I agree. But I am not convinced it would help in the
> concrete case. Even if the application detects the file is never
> than what it has instructions for, it cannot know what will fail.
> The new version might only have changes for obscure neutron
> equipment. So refusing entirely to read the file is not a sensible
> option, especially when everything appears to be in the right
> place. We may get away with it this time, because I haven't seen
> any code that would work from the detector geometry information in
> the NeXus file (alone). But we would like to see that changed
> soon.
> 
> Tobias
> 
> ________________________________________ From:
> nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on
> behalf of Watts Benjamin [Benjamin.Watts at psi.ch] Sent: 23 October
> 2012 17:02 To: Discussion forum for the NeXus data format Subject:
> Re: [Nexus] DECTRIS again
> 
> This is exactly what the NeXus version numbers should be used for.
> We should try to make clear distinctions between new and old
> formats so that software reading the files doesn't have to guess.
> 
> Ben
> 
> -----Original Message----- From: nexus-bounces at nexusformat.org 
> [mailto:nexus-bounces at nexusformat.org] On Behalf Of 
> Tobias.Richter at diamond.ac.uk Sent: Dienstag, 23. Oktober 2012
> 17:37 To: nexus at nexusformat.org Subject: Re: [Nexus] DECTRIS again
> 
> 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.
> 
> 
> 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.
> 
> 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
> 
> -- 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
> 
> 
> 
> 
> 
> _______________________________________________ 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/

iF4EAREIAAYFAlCHoWQACgkQlIP0H82W0vAcCQD+I5yIjSzBYCnUGN4A9mf+7sQG
ow/4DTW/7fRkGgjyFiIA/3w0ICsLZ5rtmt2KO9CzId6ozrdFmx0/6rE49ItXf36P
=sKfe
-----END PGP SIGNATURE-----



More information about the NeXus mailing list