[Imgcif-l] ... also

Herbert J. Bernstein yaya at bernstein-plus-sons.com
Wed Feb 17 12:38:09 GMT 2010


Having the beam profiles at various positions as images is a nice
general solution.  How about we do all of the above:

   1.  The FWHM beam sizes at the point incident on the sample
as _diffrn_radiation.beam_size...

   2.  The profiles as 0 or more images managed in a new catagory
_diffrn_radiation_profile....

   3.  The details of o or more collimators in a new catagory
_diffrn_radiation_collimator... and related categories to give
all the details of collimators as physical devices.

I think this covers what everybody has said so far. What have I missed?

   Regards,
     Herbert


=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

                  +1-631-244-3035
                  yaya at dowling.edu
=====================================================

On Wed, 17 Feb 2010, Jon Wright wrote:

> Dear Readers,
>
> If you want to have enough information to generate reflection profiles
> in a general case I think you need a lot more than you are proposing.
> Recording a 2D image (or some 1D scans) of the beam profile in different
> positions along the beamline can give a very detailed characterisation,
> but would not be suitable for everyone. With topography experiments, the
> reflection profile is an image of the crystal shape, and should be
> corrected both for the incident beam profile and detector response. It
> starts to become like a tomography experiment, where the beam profiles
> are separate images.
>
> For slit size + divergence being enough: how do you compute the profiles
> when focussing the beam on the detector versus sample?
>
> Best wishes
>
> Jon
>
>
>
> Graeme.Winter at Diamond.ac.uk wrote:
>> Hi James, Herbert,
>>
>> What you say I think is correct but not complete. For instance, if the
>> fundamental beam size is ~ 120 x 80 microns (as it is on our phase 1
>> stations here) then slits at 200 x 200 won't mean anything, but slits at
>> 80 x 80 will... Describing all of this information would help to give
>> hints about the expected beam profile - a 40 x 40 "beam" above will
>> likely be pretty uniform.
>>
>> Based on this I would propose:
>>
>> _diffrn_radiation.beam_size_x
>> _diffrn_radiation.beam_size_y
>>
>> To refer to the "fundamental" beam - that which you would receive with
>> no additional collimation - as a FWHM I assume. Then:
>>
>> _diffrn_radiation.collimation_x
>> _diffrn_radiation.collimation_y
>>
>> To refer to the recorded spacing of the slits. I could see in terms of
>> actually recording this information that this would be doable - the
>> former would be a property of the beamline, the latter a data collection
>> choice.
>>
>> Best wishes,
>>
>> Graeme
>>
>> -----Original Message-----
>> From: imgcif-l-bounces at iucr.org [mailto:imgcif-l-bounces at iucr.org] On
>> Behalf Of James Hester
>> Sent: 16 February 2010 23:14
>> To: The Crystallographic Binary File and its imgCIF application to image
>> data
>> Subject: Re: [Imgcif-l] ... also
>>
>> I agree with Herbert's suggestion, although I would name the tags
>>
>> _diffrn_radiation.beam_size_x
>> _diffrn_radiation.beam_size_y
>>
>> simply because that makes more immediate sense to me. 'Spread' reminds
>> me of 'wavelength spread', 'angular spread', 'vegemite' etc. But that
>> might just be me.
>>
>> I would advocate against the use of a slit width unless enough
>> information is provided to interpret its meaning i.e. location of the
>> slit relative to source/monochromator/sample/other slits.
>>
>> NB The powder CIF dictionary defines beam size tags for the size of the
>> beam at the sample (DDL1, however).
>>
>> James.
>>
>> On Wed, Feb 17, 2010 at 12:05 AM, Herbert J. Bernstein <
>> yaya at bernstein-plus-sons.com> wrote:
>>
>>> Another nice question.  We have the angular crossfire in
>>>
>>> _diffrn_radiation.div_x_source
>>> _diffrn_radiation.div_y_source
>>> _diffrn_radiation.div_x_y_source
>>>
>>> Should this new tag be viewed as a characteristic of the beam, say
>>>
>>> _diffrn_radiation.spread_x_source
>>> _diffrn_radiation.spread_y_source
>>> _diffrn_radiation.spread_x_y_source
>>>
>>> or, as Graeme suggests, the width of slits collimating the beam or as
>>> ???
>>>
>>> Suggestions, please.
>>>
>>> =====================================================
>>>  Herbert J. Bernstein, Professor of Computer Science
>>>    Dowling College, Kramer Science Center, KSC 121
>>>         Idle Hour Blvd, Oakdale, NY, 11769
>>>
>>>                  +1-631-244-3035
>>>                  yaya at dowling.edu
>>> =====================================================
>>>
>>> On Tue, 16 Feb 2010, Graeme.Winter at Diamond.ac.uk wrote:
>>>
>>>> Hello again,
>>>>
>>>> Is there a way to specify the size of the beam - or at least, the
>>>> gap between the slits? This obviously relates to the question
>> before.
>>>> Looking in the dictionary from version 1.5.4 - 2007-07-28 I could
>>>> not find these (this was the latest dictionary I could find in the
>>>> cbflib
>>>> distribution)
>>>>
>>>> Thanks again,
>>>>
>>>> Graeme
>>>>
>>>> Graeme Winter
>>>> Software and MX Support Scientist
>>>> Diamond Light Source
>>>>
>>>> +44 1235 778091 (work)
>>>> +44 7786 662784 (work mobile)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> This e-mail and any attachments may contain confidential, copyright
>>>> and
>>> or privileged material, and are for the use of the intended addressee
>> only.
>>> If you are not the intended addressee or an authorised recipient of
>>> the addressee please notify us of receipt by returning the e-mail and
>>> do not use, copy, retain, distribute or disclose the information in or
>>
>>> attached to the e-mail.
>>>> Any opinions expressed within this e-mail are those of the
>>>> individual and
>>> not necessarily of Diamond Light Source Ltd.
>>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>>> attachments are free from viruses and we cannot accept liability for
>>> any damage which you may sustain as a result of software viruses which
>>
>>> may be transmitted in or with the message.
>>>> Diamond Light Source Limited (company no. 4375679). Registered in
>>>> England
>>> and Wales with its registered office at Diamond House, Harwell Science
>>
>>> and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> imgcif-l mailing list
>>>> imgcif-l at iucr.org
>>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>>>
>>> _______________________________________________
>>> imgcif-l mailing list
>>> imgcif-l at iucr.org
>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>>
>>
>>
>>
>> --
>> T +61 (02) 9717 9907
>> F +61 (02) 9717 3145
>> M +61 (04) 0249 4148
>> _______________________________________________
>> imgcif-l mailing list
>> imgcif-l at iucr.org
>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>
>
> _______________________________________________
> imgcif-l mailing list
> imgcif-l at iucr.org
> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>


More information about the imgcif-l mailing list