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. thanks -grant On Wed, 1 Dec 2004 ifeffit-request@millenia.cars.aps.anl.gov wrote:
Send Ifeffit mailing list submissions to ifeffit@millenia.cars.aps.anl.gov
To subscribe or unsubscribe via the World Wide Web, visit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit or, via email, send a message with subject or body 'help' to ifeffit-request@millenia.cars.aps.anl.gov
You can reach the person managing the list at ifeffit-owner@millenia.cars.aps.anl.gov
When replying, please edit your Subject line so it is more specific than "Re: Contents of Ifeffit digest..."
Today's Topics:
1. common mono crystals (Bruce Ravel) 2. Re: common mono crystals (Matt Newville)
----------------------------------------------------------------------
Message: 1 Date: Wed, 1 Dec 2004 10:24:17 -0500 From: Bruce Ravel
Subject: [Ifeffit] common mono crystals To: XAFS Analysis using Ifeffit Message-ID: <200412011024.17160.ravel@phys.washington.edu> Content-Type: text/plain; charset="us-ascii" Hi folks,
One of my chores for today is to implement a utility in Athena for converting encoder readings in a raw data file into energy. This will make some of the data in the Lytle database a bit easier to use. One of the things that the user must specify is the d-spacing of the mono crystal. I want to provide a menu of common crystals.
The orange book is kind enough to provide an exhaustive list -- but it's kind of overkill. Somehow I doubt if many people are using a sucrose 001 monochromator even though that d-spacing is given in the orange book ;-) (Really! It's on page 4-12!)
I want to do an informal survey of what crystals the ifeffit crowd regularly uses. I am certainly going to include Si111, Si311, and Si200 in the list, so I don't need to hear from people who use those crystals. What others should go in the list? Beryl? Germanium? Graphite? Let me know....
Thanks, 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/
------------------------------
Message: 2 Date: Wed, 1 Dec 2004 09:58:12 -0600 (CST) From: Matt Newville
Subject: Re: [Ifeffit] common mono crystals To: ravel@phys.washington.edu, XAFS Analysis using Ifeffit Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII Bruce,
Diamond 111 is fairly common (I'd guess more common than anything but Si), and you probably meant Si(220) instead of (200). InSb is probably the next most common for the 1 to 2 keV range. I think the others are not so common for XAFS as the energy bandpass is too wide. Also, Si at room temperature is slightly different than at LN2 temperature....
But also needed for that calculation is the number of motor steps or encoder steps per angular unit. OK, angular unit is probably most commonly in degrees, but I wouldn't assume that it's never in radians. For steps per angular unit, it's usually a many thousand steps per degree but it can be pretty much any number.
So, it's complicated to convert 'steps' to eV. Personally, I'm comfortable insisting that the beamline/facility provide energy in eV, keV, Angstroms. or at least angle in degrees with the monochromator lattice constant clearly given.
That is, I don't think this should be athena's job. I think it would be better to have more support for beamline-specific formats. Then, if some particular beamline saves the "energy" in nanoJoules or milliradians that could be marked and auto-converted, but I don't think athena should worry about what kind of monochromator was used or steps-per-degree.
The data in the Lytle archive is possibly a special case, because it's commonly available. It's usually well marked for conversion to energy, but the data is poorly documented and spotty in quality and it's often hard to tell what exactly the columns are (e-yield v. fluorescence, for example). That can make it hard to asses the quality of the data (is self-absorption a problem, etc). I do use it sometimes, but the data is not all that reliable.
Having a more complete and well-maintained database of data, including some of the data from the Lytle database would be nice. Any volunteers to work on that?
--Matt
------------------------------
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
End of Ifeffit Digest, Vol 22, Issue 1 **************************************
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/
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
On Wed, 1 Dec 2004, Bruce Ravel wrote:
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.
Bruce: I agree with this notion. The file format we use has been loosely patterned after other beamline's formats. Perhaps it would be good to define a set of rules for a self-documenting file format plus a minimal set of information whcih needs to be present in the file. Then different beamlines can just add what they like in terms of additional documentation or details specific to the line. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
On Wednesday 01 December 2004 06:01 pm, Carlo U. Segre wrote:
On Wed, 1 Dec 2004, Bruce Ravel wrote:
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.
Bruce:
I agree with this notion. The file format we use has been loosely patterned after other beamline's formats. Perhaps it would be good to define a set of rules for a self-documenting file format plus a minimal set of information whcih needs to be present in the file. Then different beamlines can just add what they like in terms of additional documentation or details specific to the line.
Carlo
I actually had something even simpler in mind as a starting point. Things like: (1) A clear distinction between header and data (my preference would be an non-alphanumeric leading character for the header) (2) Data in columns (3) Nothing after the data (4) The data in the columns should consist entirely of floats (5) The last line of the header should contain white-space-separated column labels so the user can know what data is in which column Many beamlines already do those things, but I can think of examples of beamlines that do not do numbers 1, 4, and 5. Of course there are other cans of worms -- locale for example -- that could be addressed. But even a minimal set of guidelines would be helpful, IMHO. Other communities, the crystallographers for instance, have benefited by standardization of data exchange formats. 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/
Bruce, I want to go back a step. First, you asked what commonly used crystals athena should know about. I think the answer should be "None". Athena should not be the tool to convert mono steps to energy. It should not know the thermal expansion curve for Si. The beamline should supply values in units of energy or wavelength or provide software to convert to such units. Then the discussion got to supporting data formats from different beamlines. I don't disagree with your desired formatting rules. For what it's worth, I think we (that is, those on this email list) are as qualified to set such a standard as the IXS (or at the very least, we're approximately a quorum of any such group of the IXS). Here's a proposed draft 0.1 for a data format standard for beamline collection software: The data can be read and used by Athena without modification. Whether any such standard is actually used is a different matter. At the APS there are at least six different beamline data formats used for XAFS (there might be more than that: I'm pretty sure sectors 4, 5, 10, 12, 13, and 20 each use different formats). At least 3 of these pass the athena standard. One of those formats is spec, which does not meet this standard. I believe spec is used widely at many other synchrotrons. At the APS, some data is saved in HDF format. HDF may become more common as EPICS seems to be moving this way. I don't know that any EXAFS data is currently saved only as HDF, but I wouldn't be surprised if happens. If I'm not mistaken, SSRL saves data in a binary format. It can be converted to ASCII, but that still does not meet the 'read by athena' rule. I believe we had a recent example where data from SRS was close, but also did not quite meet this standard. But: I'm not aware of any beamline saving data in mono steps. AFAIK, only the old Lytle data is in this format. We should not do anything to encourage this very bad practice. For the record, it's bad because it assumes you know: 1) steps per degree, 2) value of steps at angle=0, and 3) lattice spacing of crystal. If you don't know all three values, you have nothing. So, I agree it would be foolish to try to support every beamline format, and not likely to be successful. I also think putting in the lattice constant for YB66 or polynomial coefficients for the thermal expansion curve of Si is a similarly doomed. --Matt
participants (5)
-
Bruce Ravel
-
Carlo U. Segre
-
Grant Bunker
-
Jeff Terry
-
Matt Newville