[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [Imgcif-l] ... also
- To: The Crystallographic Binary File and its imgCIF application to image data <imgcif-l@iucr.org>
- Subject: Re: [Imgcif-l] ... also
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Wed, 17 Feb 2010 07:38:09 -0500 (EST)
- In-Reply-To: <4B7BB2E6.5060101@esrf.fr>
- References: <4854F2500EA8C4478A508D2D92973E5206D6B2EA@EXCHANGE25.fed.cclrc.ac.uk><alpine.BSF.2.00.1002160753380.66907@epsilon.pair.com><279aad2a1002161513h77b926b1y239ee4192442e55b@mail.gmail.com><4854F2500EA8C4478A508D2D92973E5206D6B2FE@EXCHANGE25.fed.cclrc.ac.uk><4B7BB2E6.5060101@esrf.fr>
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@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@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@iucr.org [mailto:imgcif-l-bounces@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@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@dowling.edu >>> ===================================================== >>> >>> On Tue, 16 Feb 2010, Graeme.Winter@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@iucr.org >>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l >>>> >>> _______________________________________________ >>> imgcif-l mailing list >>> imgcif-l@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@iucr.org >> http://scripts.iucr.org/mailman/listinfo/imgcif-l >> > > _______________________________________________ > imgcif-l mailing list > imgcif-l@iucr.org > http://scripts.iucr.org/mailman/listinfo/imgcif-l > _______________________________________________ imgcif-l mailing list imgcif-l@iucr.org http://scripts.iucr.org/mailman/listinfo/imgcif-l
Reply to: [list | sender only]
- References:
- [Imgcif-l] ... also (Graeme.Winter)
- Re: [Imgcif-l] ... also (Herbert J. Bernstein)
- Re: [Imgcif-l] ... also (James Hester)
- Re: [Imgcif-l] ... also (Graeme.Winter)
- Re: [Imgcif-l] ... also (Jon Wright)
- Prev by Date: Re: [Imgcif-l] ... also
- Next by Date: Re: [Imgcif-l] ... also
- Prev by thread: Re: [Imgcif-l] ... also
- Next by thread: Re: [Imgcif-l] Possible bug in cbf_byte_offset.c
- Index(es):