[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