[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