[Nexus] DECTRIS again
Peterson, Peter F.
petersonpf at ornl.gov
Wed Oct 24 13:55:18 BST 2012
I think I figured it out. Ask for "Pete Peterson teleconference".
On Oct 24, 2012, at 8:51 AM, Pete Jemian <jemian at anl.gov> wrote:
> 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.
> -----------------------------------------------------------
>
>
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
More information about the NeXus
mailing list