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

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

14 Dec '04

I just put a background tutorial on my web page. Complete with project files and a pdf showing screen shots and some instructions. It used MoO3 which I found to have a particularly tough background. I used a theory to remove the background and then showed how to reproduced the "same" chi(k) data without the theory. If anyone wants to play with the background and add suggestions I will incorporate more info. Here is a link to the tutorial: www.mesg.anl.gov/skelly.html Shelly > -----Original Message----- > From: Newville, Matthew G. > Sent: Sunday, December 12, 2004 11:03 PM > To: XAFS Analysis using Ifeffit > Cc: John J. Rehr; Joshua Kas > Subject: RE: [Ifeffit] a question about the white line > > Hi John, Josh, > > > Certainly if a spline can do a good job of fitting the mu_0, then the > current > > approach is more or less ok. However in systems with strong white lines > > mu_0 can be strongly peaked and hence very difficult to fit with a few > > spline points. The broadening function lamda(E) can be constrained to be > small. > > Also, for cases with large whitelines, the location of e0 is difficult > to > > fit - the true e0 can lie well below the edge jump. > > Oh, maybe I misunderstood. Is lambda(E) in > > mu_0 = mu^thy_0(E,E_0,Gamma)[1 + lambda(E)] > > just a broadening term or a highly adjustable spline?? I guess > the whole question is how much freedom this function has. > > It definitely sounds interesting to use a theoretical mu_0, > especially for challenging white lines, but it's not clear how to > best make this accessible to users. I'll probably have to think > about this some more, but it would be nice to know the mechanics > of how you're doing it, and how well you need to know the > structure before you start. > > > In our view, mu0 does not depend very much on structure, since it's > > mostly determined by the local embedded atom potential. For this reason > > it's calculation would also be quite fast (only phase shifts and the > > cross-section are needed) compared to a calculation of chi(k) which > > requires multiple scattering paths. > > Well, usually a standard for autobk only needs a decent guess of > the first shell. Getting a standard does require some prior > knowledge of the system and calculation time, but I don't know > that it would be a lot more knowledge and time than would be > needed for a mu^thy_0(E). Anyway, it would still be interesting > to compare these two (autobk using calculated chi(k) v. starting > with a mu^thy_0 and massaging it to match data). > > On the other hand, it sounds as if the mu^thy_0(E) for a few dozen > (or few hundreds) challenging systems could be tabulated. That > would make it very fast and very simple to use! > > --Matt > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

2 1

RE: [Ifeffit] a question about the white line
by John J. Rehr 12 Dec '04

12 Dec '04

We very much appreciate Matt's comments on our suggestion suggestion on using a priori theory in fitting the background XAS: >> Thus we have attempted to use the theoretical mu_0 from FEFF as >> an a priori, and spline corrections on top of that. Thus the form >> of mu_0 would be: >> >> mu_0 = mu^thy_0(E,E_0,Gamma)[1 + lambda(E)] >> >> where the theoretical mu^thy_0 has an adjustable edge position >> (E_0) and broadening (Gamma), and lambda(E) is the spline correction >> which includes both instrumental variations with E and theoretical >> errors. Matt Newville makes the following observation: > That sounds interesting. But if you include a spline with the > calculated mu0(E), how important is the mu^thy_0(E)? Like, how > much work do you need to put into mu^thy_0 if you have lambda to > pick up the slack? Certainly if a spline can do a good job of fitting the mu_0, then the current approach is more or less ok. However in systems with strong white lines mu_0 can be strongly peaked and hence very difficult to fit with a few spline points. The broadening function lamda(E) can be constrained to be small. Also, for cases with large whitelines, the location of e0 is difficult to fit - the true e0 can lie well below the edge jump. For example, FEFF8 calculations show that the Re whiteline is almost completely due to the local embedded atomic absorption, whereas the large whiteline in SF6 has a different origin. The difference between these cases is not something that can be determined without the use of a theoretical mu0. Likewise the determination of E0 cannot be done well without theory in such cases. > On the one hand, since a spline is needed, it might imply that you > don't really gain much. On the other hand, it might also imply > that you could calculate and tabulate a reasonable 'universal > background function' for any given absorber-scatterern pair as a > starting background curve. Otherwise, it seems to me that the > prior information that goes into getting mu0(E) might be roughly > equivalent to using Feff to generate a standard chi(k) for autobk. In our view, mu0 does not depend very much on structure, since it's mostly determined by the local embedded atom potential. For this reason it's calculation would also be quite fast (only phase shifts and the cross-section are needed) compared to a calculation of chi(k) which requires multiple scattering paths. > Anyway, I'd be interested in comparisons of this with autobk > with/without a standard chi(k). And, of course, code donations > for improved algorithms are always welcome. ;). Us too! We would also be interested in sharing our code developments, e.g., eventually integrating them into ifeffit if appropriate. Josh Kas John Rehr

2 1

RE: [Ifeffit] Re: EXAFS-Question concerning \delta(k)
by Kelly, Shelly D. 10 Dec '04

10 Dec '04

Hi, > -----Original Message----- > From: Newville, Matthew G. > Sent: Wednesday, December 08, 2004 11:27 PM > To: XAFS Analysis using Ifeffit > Cc: Frank Haaß > Subject: Re: [Ifeffit] Re: EXAFS-Question concerning \delta(k) > > Hi, > > Bruce summarized Frank's questions about phase shifts as: > > > If I understand your question, there are two parts. (1) Why is > > the shift due to the phase correction always negative (i.e. > > always to a smaller value in FT[chi(R)])? And (2) Why is the > > shift always in the neighborhood of 1/2 angstrom? > > I think there is a simple way to picture why the phase shift is > negative in terms of the quantum mechanical 'scattering from a > potential' problem -- the one where you usually end up talking > about tunneling through a barrier. I'll give it a try: > > ____ ~~~~~~~> ____ > ~~~~~~>| | E<V0 | | E>V0 > __| |__ __| |__ > > > Here we're in the E>V0 regime (on the left). We normally think of > the photoelectron as having energy E= hbar^2k^2/2m, where k is the > wavenumber for the 'free' photoelectron (that is, having escaped > the central atom and far from the scattering atom). But to > participate in the EXAFS, it does leave the absorbing atom and > scatter from the neighbor. When it is near the strong potentials > of the central and scattering atom, the wavenumber would be better > written like > k = sqrt[ 2m * (E-V0)] / hbar > > as for the barrier above (where V0 is the potential energy). > That is, k is lower (the electron wavelength is longer) in the > presence of a strong potential: kinetic energy being traded for > potential energy. > > To describe the EXAFS, we use only k with V0=0, which overestimate > the average kinetic energy of the photoelectron. That means we get > fewer periods of oscillations for a given R than 2*k*R would > suggest, which leads to the negative direction of the phase shift. > [Kelly, Shelly D.] I think that my explanation for a negative phase shift is just the same, but slightly easier for my brain to comprehend. Which means that I'll make some mistakes but it works for me..:) The photoelectron is negative and it scatters off of the electrons from the surrounding atoms. Hence the photoelectron is slowed down when it gets close to the other electrons. Negative and Negative repel, giving rise to fewer periods of oscillations, and a negative phase shift. As for the magnitude of the shift, lighter elements have a larger shift than the heaver elements. You can think about that by remembering that lighter elements scatter more at low k. If you have a photoelectron that scatters with very little energy (moving slowly) it will be slowed down more by the electrons. Heaver elements scatter more at high k. So, a photoelectron that scatters with a lot of energy will not get slowed down as much, hence a smaller phase shift. HTH Shelly

2 1

Compiling Ifeffit wrapper, Athena, etc on AMD64 Linux Box
by mjpushie＠ucalgary.ca 09 Dec '04

09 Dec '04

I've been running in to some problems getting Athena, Artemis, and the other add-on packages to ifeffit, compiled on my AMD Athlon-64 Linux box (running Fedora Core 3, 64-bit version). I can run "perl Makefile.PL" without any problems and get the message: Yay! Now type "make" then "make install" to finish ... Once I run "make" it gets to the point of putting everything together and I get the following message (after the rest of it appears to run successfully): gcc -shared ifeffit_wrap.o -o blib/arch/auto/Ifeffit/Ifeffit.so -L/usr/local/lib -lifeffit -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/bin/ld: /usr/local/lib/libifeffit.a(ifeffit.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libifeffit.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [blib/arch/auto/Ifeffit/Ifeffit.so] Error Thus far I have: 1) Successfully installed PGPLOT-5.2.0, editing the makefile to read: LIBS=-L/usr/X11R6/lib64 -lX11 `$(SRC)/cpg/libgcc_path.sh` -lgcc -lm -lc instead of ... -L/usr/X11R6/lib -lX11 ... 2) Successfully installed ifeffit-1.2.6 after editing: src/Makefile src/cmdline/Makefile src/test/Makefile to contain: PGPLOT_LIBS = -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib64 -lX11 instead of ... -L/usr/X11R6/lib -lX11 ... 3) Successfully installed Tk-804.027 after editing Makefile.PL to read: X11LIB=/usr/X11R6/lib64 4) began installing the ifeffit wrapper, athena and artemis with $ perl Makefile.PL (which completed successfully) $ make (gives errors) I've edited the Makefile in the horae-046 directory where ifeffit_wrap.c and ifeffit_wrap.o are located to append -fPIC following the call to gcc, producing: gcc -shared ifeffit_wrap.o -fPIC -o blib/arch/auto/Ifeffit/Ifeffit.so -L/usr/local/lib -lifeffit -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/bin/ld: /usr/local/lib/libifeffit.a(ifeffit.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libifeffit.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [blib/arch/auto/Ifeffit/Ifeffit.so] Error 1 I'm no compiling wizard, and I'm not even certain that -fPIC is supposed to be passed to gcc in this manner. Is there some other way around the whole shared/static thing, or is this not even the real issue? If anyone on the list has any suggestions, by all means please send them along. I'd like to get some work done!! Sorry for the length of the post. Jake

4 3

Re: EXAFS-Question concerning \delta(k)
by Bruce Ravel 08 Dec '04

08 Dec '04

Frank, I am taking the liberty of forwarding my answer to the Ifeffit mailing list. I am not sure that I can answer your question entirely to your satisfaction and thought it would be useful to offer it up to the list for more commentary. > It is well known that there is a difference in the peak maxima of the > Fourier transformed EXAFS, G(r), and the "real" pair distribution function, > say F(r). As I have observed in spectra taken on pure metals, the maxima of > G(r) and the calculated core-shell-distances (calculated out of the crystal > structure) coincide pretty good. On oxidic samples, this is not the case, > G(r) is always shifted to lower r-values, about 0.5 \AA, sometimes even > almost 1 \AA. I agree that the shift due to the phase might be smaller for a pure metal than for an oxide, but it isn't 0. For copper, for instance, the highest point of the first peak is about 1/4 angstrom lower than the distance to the first shell. > It is always said that this difference is due to the phase shift \delta(k) > in the EXAFS equation, but I have not found a reasonable explanation, WHY > \delta(k) is influenced in this way! What are the parameters "behind" > \delta(k)? > > Maybe you have a little time to answer my question, because I am really not > satisfied with the explanations I found in literature. If I understand your question, there are two parts. (1) Why is the shift due to the phase correction always negative (i.e. always to a smaller value in FT[chi(R)])? And (2) Why is the shift always in the neighborhood of 1/2 angstrom? This is one of those things that I take for granted and rarely think too hard about. Here are my stabs at decent answers to your questions. I'll try the second part first. I wnet all the way back to the Lee and Beni paper from 1977 (Phys Rev B v.15 #6, p. 2862) which shows some plane wave calculations of the various central atom phase shifts. (There are lots of reasons to look at later papers as we now know that curved wave effects are very important, but for motivating a quick 'n' dirty understanding, it is useful to think about plane waves.) These are shown in Fig. 5 on page 2868. There is a Z dependence -- Rh is very different from Mg in the plot -- but all of them have essentially the same k dependence. That is, the traces in that plot are roughly parallel. We can approximate those phase shifts as linear -- 2delta = a*k + b. (They are obviously not linear but the quadratic term isn't huge, and it's helpful to keep the argument simple.) With this assumption, we are Fourier transforming an exafs function with a sine term like this: sin( 2kR + a*k + b) = sin( (2R+a)*k + b ) When you Fourier transform this, the peak will be shifted away from the "correct" R value by a/2. As you can see in the figure in Lee&Beni, all these functions are downward-sloping. Thus a is a negative number, resulting in an inward shift of the peak. All the central atoms have about the same slope, so they are all shifted by about the same amount. Any variation would have to do with the phase shift of the scatterer. So why is the slope of the central atom phase shift always negative and never positive? I think I am going to be less helpful for this question, but maybe someone else can pick up the slack. When you solve the problem of scattering of partial waves off a hard sphere, you find that each partial wave has a phase shift of -pi/2 times the angular momentum of the partial wave. That is, the effect of the scattering is to *decrease* the phase of the particle scattered in a way that is dependent on the angular momentum. An atom isn't a hard sphere and the calculation is a lot harder than for a hard sphere, but the essential physics is the same. Of course, this discussion has been hand-waving. For a proper understanding of all this stuff, I recommend the important Rehr-Albers review of XAS in Rev. Mod. Phys. v.72 #3 (2000) pp 621-654. Indeed, anyone who does XAS regularly should probably keep a copy of that paper on the desk. HTH, B > Thanks!! > > Yours, > > Frank > > --- > Dipl.-Ing. Frank Haass > Darmstadt University of Technology > Institute for Materials Science / Structure Research > Petersenstrasse 23 > D-64287 Darmstadt > > Tel.: +49 (0) 6151 16-2697 > Fax: +49 (0) 6151 16-6023 > > eMail: haass(a)tu-darmstadt.de -- 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 1

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

08 Dec '04

Hi Bruce, I have worked with tough background removals. They are particularly difficult the first time you encounter each one. My methodology goes something like this. It isn't easy and sometimes very frustrating. 1) Determine how broad the rise in the adsorption edge. How many eV is it from the bottom to the flat part above the edge. If you edge is broad > 10 eV then Ezero will be somewhere high on the adsorption edge. If you edge is sharp then Ezero will be somewhere low on the adsorption edge. 2) Remove the background. Look at the FT with all three k-weights. Determine if Rbkg is reasonable. 3) You must have a good idea about the first shell. Run Feff and look at the theory with all variables set to zero, Ezero =0, sigma2=0 and delr=0. If you have a split shell be sure to include all the paths that make up the first peak in the FT of the data. 4) Compare theory to data using a well padded k-range. Leave out the first two oscillations in k, starting around 4 to 5 inverse angstroms. Set Ezero equal to zero. Run a fit, determine delr for the paths and sigma2. Look at the fit and the data in k-space with all three k-weights. Check to see if delr and sigma2 are reasonable. See if you think that moving Ezero around in Athena will help line things up at low k. 5) Import the "fit" into Athena and use it as the theory. Remove the background moving Ezero to line up the data and the theory at low k. And then start all over. 6) This procedure will not work if you use the wrong theory hence the frustrating part. HTH - If someone on the list is willing to try this procedure out and gets stuck and you are willing to share all. I will continue to help on the mailing list. Shelly Shelly Kelly ---------------------------- skelly(a)anl.gov Bldg 203, RM E113 phone: (1) 630-252-7376 Argonne National Laboratory fax: (1) 630-252-9793 Argonne, IL 60439 www.mesg.anl.gov > -----Original Message----- > From: Bruce Ravel [mailto:ravel@phys.washington.edu] > Sent: Tuesday, December 07, 2004 3:00 PM > To: XAFS Analysis using Ifeffit > Subject: Re: [Ifeffit] a question about the white line > > On Tuesday 07 December 2004 03:47 pm, you wrote: > > Hi Bruce, > > > > Feel free to have them contact me. I have done a lot of Re compounds. > > > > Jeff > > Hmmm.... The point of a mailing list is to have a public, searchable > archive where useful information can be discussed and shared in an > open manner. > > I could have just answered the question myself, but I thought that it > was one of broad interest. Thus I had hoped to solicit discussion on > the mailing list. > > 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/ > > > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

5 6

Frustrating monochromator glitch
by m.bondin＠pgrad.unimelb.edu.au 08 Dec '04

08 Dec '04

Dear mailing list - my last round of EXAFS experiments performed on the Fe-K edge in fluorescence mode gave data extending nicely to 15 in k. One problem was a nasty monochromator glitch at approx 13.5 in k which is so great in some cases it causes sufficient distortion to the data that even upon deglitching I must cut back the data to 13 in order to gain a good fit using my models. Firstly I was wondering if someone here could describe to me how a monochromator glitch arises (some systematic defect in the monochromator crystal or more? - the only problem with this explanation is that some data sets seem more affected than others and it has not manifested itself as badly in previous trips). Also is there any other way to handle the removal of a monochromator glitch besides deglitching? My supervisor seems to think that there must be a scale factor or offset in the I0 monitor counts which could be corrected in order to overcome a glitch in the existing data - has anyone ever ! thought of other ways to salvage data in this way? Regards, Mark -- Mark Bondin PhD student School of Chemistry, University of Melbourne (03) 8344 7015 (Tower lab) 0409 252 983 (mobile)

3 2

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