[Nexus] DECTRIS again
Pete Jemian
prjemian at gmail.com
Wed Oct 24 13:49:14 BST 2012
Mark and I are at the telecon. Could there be two telecons?
On 10/24/2012 7:48 AM, Wintersberger, Eugen wrote:
> -----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-----
>
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
>
More information about the NeXus
mailing list