[Nexus] DECTRIS again
Pete Jemian
jemian at anl.gov
Wed Oct 24 13:51:05 BST 2012
called 865-574-1000 and requested to connect to Pete Peterson's
conference call
She was very nice
On 10/24/2012 7:49 AM, Pete Jemian wrote:
> 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
>>
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
--
----------------------------------------------------------
Pete R. Jemian, Ph.D. <jemian at anl.gov>
Beam line Controls and Data Acquisition, Group Leader
Advanced Photon Source, Argonne National Laboratory
Argonne, IL 60439 630 - 252 - 3189
-----------------------------------------------------------
Education is the one thing for which people
are willing to pay yet not receive.
-----------------------------------------------------------
More information about the NeXus
mailing list