[Nexus] DECTRIS again
Wintersberger, Eugen
eugen.wintersberger at desy.de
Wed Oct 24 14:19:35 BST 2012
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I do not think that it makes too much sense joining the telecon now.
For me the suggestion of Tobias using NXdetector_module is ok and I
guess the confusion on exposure_time has already been solved too.
regards
Eugen
PS: I got the mail a bit late as I am actually cleaning up my mailbox
wich is unfortunately full (as I learned now from a mail of our
administrators).
On 10/24/2012 02:55 PM, Peterson, Peter F. wrote:
> 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:
> 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
>
>
>>>>
>>>> _______________________________________________ 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
>
>
> _______________________________________________ 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/
iF4EAREIAAYFAlCH6ucACgkQlIP0H82W0vDDpQD8D6a6tzy7ucbQxrjUX++NVZBd
TN/z9oBc0tl4HlG2dA8BAInIAjDxLuKulwjhCZ0A+ShaRqiR+LbplTSuVfQTB1rY
=235A
-----END PGP SIGNATURE-----
More information about the NeXus
mailing list