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@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@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit