- Ifeffit - millenia.cars.aps.anl.gov

RE: [Ifeffit] a question about the white line
by Barton, David (DG) 08 Dec '04

08 Dec '04

Friends, Thanks Bruce for forwarding the question to the Ifeffit mailing list regarding background subtraction for samples with strong white lines. The Re sample that sparked the question is attached (white line >3mu). The data is not perfect, but it is good enough for discussion. My first approach to subtracting the background was similar to what Matt mentioned (Matt said: "I know others regularly use kmin >1"), this method seemed to work fairly well using kmin= 1.5 and Rbkg = 1.0. I then used Matt's suggestion to shift the Eo and keep kmin = 0.5, this method ultimately gave a similar subtraction albeit with a phase shift that should be taken care of when the data is fit to theory. It will be interesting to compare the results of the fit using these two methods of background subtraction, especially the first shell which is a Re-CO that has a short distance and is sensitive to background subtraction. Thanks, Dave _________________________________ David Barton, PhD The Dow Chemical Company Catalysis R&D 1776 Building Midland, MI 48674 USA Ph: (989) 636-4753 Fax: (989) 638-6225 Email: dgbarton(a)dow.com

1 0

RE: [Ifeffit] a question about the white line
by Kelly, Shelly D. 08 Dec '04

08 Dec '04

> -----Original Message----- > From: Newville, Matthew G. > Sent: Tuesday, December 07, 2004 11:17 PM > To: XAFS Analysis using Ifeffit > Subject: RE: [Ifeffit] a question about the white line > > Shelly, > > That seems like a lot of steps to me, and it almost seems like > you're mimicking by hand the use of a standard chi(k) with > autobk/spline(). Do you find very different results using a > standard chi(k) with autobk/spline()? If so, do you have any > suggestions for how the more automated version could be improved? > [Kelly, Shelly D.] Hi Matt, You are right. My method does use a lot of steps. I have seen "large" differences in the background removal for the first two full cycles in k-space. I will show a figure, soon. But often what happens is the default spline cuts the EXAFS data too many times through the edge. Your suggestion for an automated approach is a good one. Here is an idea. (1) Set kmin high in the spline range, so that you do not use the first two oscillations in k. (2) Fit the first shell, in a way that makes sense. (3) Use the theory to remove the background using kmin=0 in the spline range. As Matt points out you can tell if the theory is reasonable by the shape through the white line region. You will get to the same place as before. -Assuming that you use a reasonable theory and your original choice of Ezero is not too far off. I will try it out on some tough data and let you know how it goes. Shelly

1 0

Exporting data to Igor
by Gerrit Schmithals 08 Dec '04

08 Dec '04

Hello, I now frequently use the possibility of exporting data from Athena to my analysis software Igor Pro 5. I have a few suggestions on the exporting behaviour: - The abscissa-column of exported BFT data (q-space) is wrong when using File | Save marked group as data | ... This applies to the magnitude, real and imaginary part. Obviously the R-space values are used instead of q-space as can be seen from the column header. When using File | Save chi(q) no problems occur. (see Data.zip, Athena 0.8.034, Ifeffit 1.2.6a) - Along with exporting the data I also use Edit | Write a report | CSV report (marked groups) to get a printout of all parameter values with which the data was processed. I have written a small script for Igor to read that data into a text wave from where it can be displayed or used in further routines e.g. to automatically be displayed in a graph. If anyone is interested I can post that script. Bruce, if there is time left for it, could you also include the value of the check button 'Phase correction' along with the exported data? (BTW: The unchecked button displays either 'No' or 'Off' but it seems irrelevant) Cheers, Gerrit

2 1

a question about the white line
by Bruce Ravel 07 Dec '04

07 Dec '04

Hi, Last week I was asked an interesting question. A long-time ifeffit user was showing A&A to some grad students new to the XAS biz: [An] issue that came up with them as they began to use the software was: Dealing with background substraction from compounds with enormous white lines (Re data). I thought it would be useful to hear comments from people on the mailing list. Any takers? B -- Bruce Ravel ----------------------------------- ravel(a)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/

2 2

RE: [Ifeffit] Re: Ifeffit Digest, Vol 22, Issue 1
by SCHLEGEL Michel 177447 06 Dec '04

06 Dec '04

> > 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. > > > > I think that Matt is right. > > It is a shame to waste the old Lytle data, but let us not > allow that to continue. If someone really wants the data > from that old Lytle data bank then there are inconvenient > ways to extract the information, just as it should be. Would it be advisable - realistic to convert once and for all the old Lytle data from the mono step scale to the energy scale? (I mean, by wirtue of a well-hacked perl macro). Is there any scientific reason why the old mono step scale should be kept? > I second the "Athena test". As such, spec files with all scans cannot be read by Athena, but you can copy out individual "scans" in separate files, for which comment lines all start with "#", the last line given the name of the motors and detectors ("energy", "IO"...) and the data is then ordered as an array. The promblems are (1) usually all scans (table, slits...) are collected in one file, and (2) the column ordering varies from file to file (a problem which is already wonderfully addressed by Athena, though). So maybe a separate splitting macro to take out the do the job would be more convenient than asking athena to do all theis work. Granted it's tedious, but compared to the time needed to correctly extract, interpret & fit the data... Michel

5 8

Re: differential evolution algorithm (fwd)
by Grant Bunker 02 Dec '04

02 Dec '04

Carlo suggested that I submit this (edited) to the ifeffit list... gb ---------- Forwarded message ---------- Date: Thu, 2 Dec 2004 21:40:54 -0600 (CST) From: Grant Bunker <bunker(a)agni.phys.iit.edu> To: Carlo U. Segre <segre(a)iit.edu> Cc: Bruce Ravel <ravel(a)phys.washington.edu>, Grant Bunker <bunker(a)biocat1.iit.edu> Subject: Re: differential evolution algorithm Hi, Carlo - DE is a very nice and simple genetic algorithm for finding global minima. As far as I know I have been the only person applying it to XAFS. It might be overkill for the application though - is this just for finding maximum in the edge derivative? If it is, it's probably simpler just to smooth the data (e.g. with binomial smoothing which you can do by repeated convolution Y(n)=y(n+1)+2*y(n)+y(n-1))/4), followed by a derivative. I've done it that way before (or use smoothing splines) in the distant past and it worked fine. In the edge-finding hack in the mathematica notebook (for automated data reduction) I sent you I just used differential evolution out of laziness, but it's very good for more difficult fitting problems like the stuff we have been doing with the ab initio DWFs in enzymes. It's arguable whether using the max derivative is the best way to choose E0 anyway, but that's a different story. thanks - grant ps I googled "differential evolution" and uncovered a good web site at berkeley. Probably it has references to the original article by storn and price. A couple of years ago I implemented it in Mathematica code for global fitting calling feff as an external "function". The intrinsic NMinimize function in Mathematica also has it available as a minimization method in purely numerical (nonsymbolic) calculations. http://www.icsi.berkeley.edu/~storn/code.html On Thu, 2 Dec 2004, Carlo U. Segre wrote: > > I am somewhat ignorant. Grant uses the builtin function from Mathematica. > Perhaps he can give a bit more information. Grant? > > Carlo > > On Thu, 2 Dec 2004, Bruce Ravel wrote: > > > > >> Grant has been using a differential evolution algorithm to take case of > >> noisy data. Perhaps this could help? > > > > Carlo, > > > > Is there a reference for this in the exafs conmtext? I'd like to read > > up on it. > > > > B > > > > > > > > -- > 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(a)iit.edu http://www.iit.edu/~segre >

1 0

RE: [Ifeffit] Too many points in pre-edge
by Barton, David (DG) 02 Dec '04

02 Dec '04

Carlo and Matt: > With these files, the location of the edge (and element > identification as well) using the first derivative > does not work. I also had a similar problem when we had a somewhat noisy pre-edge and edge data. Often our analysis of the XANES requires high confidence in the edge energy to determine energy shifts and to accurately align our spectra using metal foil references. Of course, I can always manually assign the edge position in Athena, but it would be nice if Ifeffit was a bit smarter about how it chooses Eo since it is critical for Athena operation when a reference standard is used to calibrate a sample spectra. I would guess that there is some robust algorithm that one could implement which would more accurately determine either (1) the maximum in the first derivative or (2) the zero of the second derivative for data with any number of data points or noisy data. I imagine that such an algorithm would include some sort of adjustable "smoothing" parameter to filter the signal from noise. Dave _________________________________ David Barton The Dow Chemical Company Catalysis R&D 1776 Building Midland, MI 48674 USA Ph: (989) 636-4753 Fax: (989) 638-9350 Email: dgbarton(a)dow.com > -----Original Message----- > From: ifeffit-bounces(a)millenia.cars.aps.anl.gov > [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On > Behalf Of Carlo U. Segre > Sent: Thursday, December 02, 2004 9:44 AM > To: IFEFFIT Mailing List > Subject: [Ifeffit] Too many points in pre-edge > > > > Matt: > > I am running into a somewhat annoying problem with > continuous scan data > imports into athena where there are many datapoints before > the edge (I > think > 400 or so). With these files, the location of the > edge (and > element identification as well) using the first derivative > does not work. > The edge is identified as being somewhere in the pre-edge. > As I reduce > the number of data points in the pre-edge, the edge > identification moves > closer to the true edge and then locks in correctly when > the number of > data points in the pre-edge is small enough (again, I think > this is less > than 400 points). > > I can address this problem by running these data through a > rebinning > process in the pre-edge but I think that if it is possible > to handle this > in ifeffit, that would be a good idea. > > On a second note, would you tell me whether you or Bruce is > planning to > maintain the ifeffit perl wrapper? At this time, ifeffit > 1.2.6a and horae > 046 have different versions of the Ifeffit.pm script (1.3 and 1.301 > respectively). I recently ran into a problem because I had > the ifeffit > version and horae 046. > > 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(a)iit.edu http://www.iit.edu/~segre > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >

4 5

RE: [Ifeffit] Re: Ifeffit Digest, Vol 22, Issue 1
by Kelly, Shelly D. 02 Dec '04

02 Dec '04

> > 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. > I think that Matt is right. It is a shame to waste the old Lytle data, but let us not allow that to continue. If someone really wants the data from that old Lytle data bank then there are inconvenient ways to extract the information, just as it should be. I second the "Athena test". Shelly

1 0

Too many points in pre-edge
by Carlo U. Segre 02 Dec '04

02 Dec '04

Matt: I am running into a somewhat annoying problem with continuous scan data imports into athena where there are many datapoints before the edge (I think > 400 or so). With these files, the location of the edge (and element identification as well) using the first derivative does not work. The edge is identified as being somewhere in the pre-edge. As I reduce the number of data points in the pre-edge, the edge identification moves closer to the true edge and then locks in correctly when the number of data points in the pre-edge is small enough (again, I think this is less than 400 points). I can address this problem by running these data through a rebinning process in the pre-edge but I think that if it is possible to handle this in ifeffit, that would be a good idea. On a second note, would you tell me whether you or Bruce is planning to maintain the ifeffit perl wrapper? At this time, ifeffit 1.2.6a and horae 046 have different versions of the Ifeffit.pm script (1.3 and 1.301 respectively). I recently ran into a problem because I had the ifeffit version and horae 046. 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(a)iit.edu http://www.iit.edu/~segre

1 0

Re: Ifeffit Digest, Vol 22, Issue 1
by Grant Bunker 01 Dec '04

01 Dec '04

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(a)millenia.cars.aps.anl.gov wrote: > Send Ifeffit mailing list submissions to > ifeffit(a)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(a)millenia.cars.aps.anl.gov > > You can reach the person managing the list at > ifeffit-owner(a)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 <ravel(a)phys.washington.edu> > Subject: [Ifeffit] common mono crystals > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: <200412011024.17160.ravel(a)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(a)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 <newville(a)cars.uchicago.edu> > Subject: Re: [Ifeffit] common mono crystals > To: ravel(a)phys.washington.edu, XAFS Analysis using Ifeffit > <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: > <Pine.LNX.4.44.0412010940170.26700-100000(a)millenia.cars.aps.anl.gov> > 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(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest, Vol 22, Issue 1 > ************************************** >

5 5