[Ifeffit] Re: Ifeffit Digest, Vol 22, Issue 1

[Jeff Terry]

YB66 would be another good crystal to have in the database.

I believe that it is the 400 reflection that is used in monochromators.

Jeff


On Dec 1, 2004, at 3:09 PM, Bruce Ravel wrote:

> On Wednesday 01 December 2004 03:41 pm, Grant Bunker wrote:
>> Hi, Bruce - Ge crystals certainly are a must. Shouldn't forget that 
>> people
>> use Si monochromator crystals at different temps also. Instead of 
>> making
>> a list of d spacings for each reflection, I would just keep values of 
>> the
>> lattice constants at a few reference temps and interpolate the lattice
>> constant a for the temp of interest, then any of the d spacings can be
>> calculated as d[hkl]=a/Sqrt[h^2+k^2+l^2] (if memory serves me 
>> correctly)
>> Same for Ge and Diamond since they are the same structure. That way 
>> it's
>> just a handful of numbers, no big deal.
>>
>> Matt's point as to whether it really should be athena's job to read 
>> in all
>> file formats is a good one. Mostly you want to make it easy for a
>> new format to be added by the end user. A scripting language would
>> suffice although perl might be difficult for most people to deal with.
>> Perhaps the equation parser used in ifeffit could be deployed as 
>> end-user
>> configurable preprocessor for massaging beamline data into the right
>> form. If those were saveable as templates for different types of data 
>> it
>> would be convenient.
>
> Hi Grant,
>
> Thanks for the comments.
>
> I am indeed computing d-spacings from lattice constants.  The notion
> of interpolating from a table for different temperatures is a good
> solution.
>
> I have actually been suprised at how small of a deal it has been to
> handle different data file formats.  It turns out that almost
> everyone's beamline spits out data that ifeffit and athena's column
> selection dialog can handle just fine.  There are a few exceptions,
> but not many.  In any case, I find that encoder readings fit into
> Athena's column selection dialog well enough that it's worth
> supporting.
>
> I agree that it's a fool's game trying to stay on top of every single
> goofy format that too-clever-by-half DAQ software programmers have
> come up with.  Much better than that would be to suggest standards for
> an exafs data file format.  At this late date, we have a pretty good
> grasp of the technology involved in exafs measurements and so we know
> what needs to be in the file.  If someone -- say the International
> XAFS Society -- were to publish a standard, it would provide guidance
> that would benefit the programmers of DAQ software, of analysis
> software, and of any tools to link the two.
>
> B
>
>
>
> -- 
>  Bruce Ravel  ----------------------------------- 
> ravel at phys.washington.edu
>  Code 6134, Building 3, Room 405
>  Naval Research Laboratory                          phone: (1) 202 767 
> 2268
>  Washington DC 20375, USA                             fax: (1) 202 767 
> 4642
>
>  NRL Synchrotron Radiation Consortium (NRL-SRC)
>  Beamlines X11a, X11b, X23b
>  National Synchrotron Light Source
>  Brookhaven National Laboratory, Upton, NY 11973
>
>  My homepage:    http://feff.phys.washington.edu/~ravel
>  EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
>
> _______________________________________________
> Ifeffit mailing list
> Ifeffit at millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit