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

re:fits
by k-kupiecki＠northwestern.edu 15 Jan '05

15 Jan '05

Thank you Bruce and Shelley! I just wanted to thank Matt, Bruce and everyone involved with IFEFFIT/Artemis/Athena... it has been a Godsend.... I couldn't have stumbled on it at a better time (I'm frantically trying to analyze about 4 beamtimes worth of SEXAFS data for papers and my thesis and WINXAS wasn't really working out for me)!!!!! Does anyone have any suggestions for additional literature in regards to better understanding the quality of fits and the parameters involved?.... or perhaps know when we might be able to expect a updated version of the Artemis literature? (What is currently there has helped me sooo much that I've been checking for an update every couple of weeks hoping to get see sections 2.2-3.2..... ) Also.... I guess I've realized that only knowing IFEFFIT with Artemis I kinda take things for granted (like I didn't know that IFEFFIT was having problems, in certain cases since I had only been checking the "Results" and the error messages on the bottom of the window....) which meant I missed errors like this in the IFEFFIT (since I didn't notice anything unusual in the "Results"): ............ # Do the fit! ## fitting difference of Cov_0_06ML_bl1435_111703.chi and one or more paths ... ## === data set #1 of 1 feffit(1-8, group=data0_fit, chi=data0.chi, k=data0.k, kweight=2.00, rmin=1, rmax=4, kmin=2.5, kmax=15, dk=2, kwindow=kaiser-bessel, fit_space=R, do_bkg=no, data_set=1, data_total=1) feffit fitting 1 data sets fitting ... fitting ... fitting ... fitting ... fitting ... fitting ... fitting ... fitting ... no uncertainties estimated! fit gave a warning message: too many fit iterations. try again with better guesses or a simpler problem. ............................................... I guess my question is.... is there anything else I should be looking for in the IFEFFIT printout that I might not otherwise notice by just using Artemis and looking at the error messages and "Results"? Thanks for the input! Sincerely, Kristine Witkowski Northwestern University

6 8

Athena & Artemis in Windows
by Peter Southon 22 Dec '04

22 Dec '04

Hello Windows people A few days ago Shelly suggested that Athena and Artemis don't work when installed in the directory "C:/program files/ifeffit/". This has always worked for me using XP, though I wouldn't be surprised if it caused problems in some earlier versions of Windows. Regarding Poorani's question about TRAP files, I have found it useful to put a shortcut to "C:/program files/ifeffit/horae/stash/ARTEMIS.TRAP" on my desktop or wherever for easy access. Cheers, Peter >Date: Fri, 11 Jun 2004 08:36:32 -0500 >From: "Kelly, Shelly D." <SKelly(a)anl.gov> >Subject: RE: [Ifeffit] Running FEFF >To: "XAFS Analysis using Ifeffit" <ifeffit(a)millenia.cars.aps.anl.gov> >Message-ID: <1C1577844A0BDF448E14E8CCB2F74424015A1B6D(a)ANLMAIL.anl.gov> >Content-Type: text/plain; charset="us-ascii" > >Hi Poorani, > >I believe that Athena and Artemis do not work properly when installed in >the C:/program files/ifeffit directory. The installation proceedures >say to specify C:/ifeffit instead. To fix if, but all of C:/program >files/ifeffit into the trash and then re-install. > >Shelly Peter Southon Post Doctoral Fellow School of Chemistry University of Sydney NSW 2006, Australia +61 2 9351 4425

5 4

RE: [Ifeffit] Using more than one E0
by Kelly, Shelly D. 15 Dec '04

15 Dec '04

Hey Scott, One correction, I botched this part: > -----Original Message----- > From: Kelly, Shelly D. > Sent: Wednesday, December 15, 2004 10:06 AM > To: XAFS Analysis using Ifeffit > Subject: RE: [Ifeffit] Using more than one E0 > > Hi Scott, > > See below: > > The MS scheme you outline below seems to treat the E0 due to the > scattering species (I'll call that the "bonus" E0 for lack of a better > term) as being the average of the bonus E0's for all the scattering > atoms > in the path. Thus you give the Cu-O1-Cu1-Cu path as using the average of > the O1 and the Cu1 bonus E0's, while the Cu-O1-Cu-O1 path uses just the > O1 bonus E0. I would naively expect we should be using the sum, rather > than the average. After all, if this bonus E0 is a correction to the > shift caused by the muffin-tin potential FEFF has calculated, shouldn't > a > MS path that bounces off the same atom twice have to use twice the > correction? I feel like there's something basic I'm missing here... > > [Kelly, Shelly D.] The energy shift applies to the entire scattering > event. The scattering event can not be broken down into the sum of the > legs. [Kelly, Shelly D.] Most of the time, it is good to think about the scattering event as being a sum of the legs. If you follow this through you can see why the energy shift is an average rather than a sum. Take two sine waves and displace one from the other by a few eV. Then add them up. The total will have an energy shift that is in between the two that you started out with. --Hence an average rather than a sum. Hence the energy shift for the entire scattering event can be > approximated as an average of the energy shift from each leg. I have > used the average energy shift a lot and found that it works well. I > have never tried using a sum of the energy shifts... I think that in > an extreme limit you can convince yourself that the sum will break down > for an 8 legged paths. The energy shifts are "never" greater than 10 > eV. "never" in my experience. -Hence the answer to your next question. > > Also, what is your experience as to the actual differences in bonus E0's > that you get in ionic compounds? Right now one of my students is working > with Sr(NO3)2... should we really expect the difference in bonus E0's > between the Sr2+ and the oxygen atoms to be more than 12 eV, or does > some > kind of charge overlap from the nitrate ions actually make the strontium > ions behave as if they are less than +2? > > [Kelly, Shelly D.] One full electron of ionic bonding gives about 6 eV. > So that is about the most you would expect from different ions in a > solid. Usually, I have found 3 to 4 eV. You make up most of the > valence state change from the shift in the edge position. I have found > unrealistic energy shifts when I try to use too much chi(k) data at low > k. I'd look there first for you 12 eV shift. > > HTH > Shelly > > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

1 0

RE: [Ifeffit] Using more than one E0
by Kelly, Shelly D. 15 Dec '04

15 Dec '04

Hi Scott, See below: The MS scheme you outline below seems to treat the E0 due to the scattering species (I'll call that the "bonus" E0 for lack of a better term) as being the average of the bonus E0's for all the scattering atoms in the path. Thus you give the Cu-O1-Cu1-Cu path as using the average of the O1 and the Cu1 bonus E0's, while the Cu-O1-Cu-O1 path uses just the O1 bonus E0. I would naively expect we should be using the sum, rather than the average. After all, if this bonus E0 is a correction to the shift caused by the muffin-tin potential FEFF has calculated, shouldn't a MS path that bounces off the same atom twice have to use twice the correction? I feel like there's something basic I'm missing here... [Kelly, Shelly D.] The energy shift applies to the entire scattering event. The scattering event can not be broken down into the sum of the legs. Hence the energy shift for the entire scattering event can be approximated as an average of the energy shift from each leg. I have used the average energy shift a lot and found that it works well. I have never tried using a sum of the energy shifts... I think that in an extreme limit you can convince yourself that the sum will break down for an 8 legged paths. The energy shifts are "never" greater than 10 eV. "never" in my experience. -Hence the answer to your next question. Also, what is your experience as to the actual differences in bonus E0's that you get in ionic compounds? Right now one of my students is working with Sr(NO3)2... should we really expect the difference in bonus E0's between the Sr2+ and the oxygen atoms to be more than 12 eV, or does some kind of charge overlap from the nitrate ions actually make the strontium ions behave as if they are less than +2? [Kelly, Shelly D.] One full electron of ionic bonding gives about 6 eV. So that is about the most you would expect from different ions in a solid. Usually, I have found 3 to 4 eV. You make up most of the valence state change from the shift in the edge position. I have found unrealistic energy shifts when I try to use too much chi(k) data at low k. I'd look there first for you 12 eV shift. HTH Shelly

1 0

RE: [Ifeffit] Using more than one E0
by Kelly, Shelly D. 15 Dec '04

15 Dec '04

Hi Guys, I wanted to add another comment about using multiple E0's. One of the best formulas that I have found involves assigning different atom types different E0's. This method seems to work well for M.S. paths. Here is an example of how it goes. I think that Daniel Haskel was the first to publish this type of E0 stuff. "Single and multiple scattering XAFS in BaZrO3: a comparison between theory and experiment" D. Haskel, B. Ravel, M. Newville and E. A. Stern Physica B 208&209 (1995) 151 Lets pretend that we have a copper oxide that we want to model. First shell Oxygen called O1, Second shell Cu called Cu1, Third shell Oxygen called O2. This method would use three E0's. One for the first shell oxygen atoms, Eo1. One for all the Cu atoms Ecu. and one for all other oxygen atoms Eo2. The Cu-O1 path has E0=Eo1. The Cu-Cu1 path has E0=Ecu. The Cu-O2 path has E0=Eo2. The Cu-O1-Cu-O1 path has E0=Eo1, (only scattering from O1 atom). The Cu-O1-Cu1-Cu path has E0=0.5*Eo1+0.5*Ecu. (scattering once from O1 and once from Cu1) ... And so forth and so on. Now if you set something like this up. You need to look at the results carefully and see if it works. Generally, scattering from an atom that has lost an electron due to an ionic bond will have a positive deltaE, and scattering from an atom that has gained an electron will have a negative deltaE. Of course this negative/positive deltaE is added to the alignment deltaE. If the values for Eo2 and Ecu are the same within the uncertainties of the measurement then you need to make them the same variable, so then you will only have two energy shifts, but you can still use it. This is most often the case as Matt mentioned but I always like to test it out. In addition, one electron transfer is about a shift by 6 eV, so if these values differ by more than say 10 eV something is not right. Since the shift is generally smallish, say 2 eV, your fit has to be really accurate to "see" these shifts. In particular they seem to be most important when you have all the deltaR values constrained in some way so that the error in deltaR is really really small. For example all deltaR values are related to unit cell parameters and atomic positions or and overall expansion term. HTH Shelly -----Original Message----- From: Wojciech Gawelda [mailto:wojciech.gawelda@epfl.ch] Sent: Thursday, May 27, 2004 1:18 PM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: [Ifeffit] Using more than one E0 Hi everybody, I would like to address a couple of questions which are partially related to my recent struggles in fitting some EXAFS data. I'm trying to fit my data using several shells of different neighbors including a few single scattering paths and also so multiple scattering contributions (mainly collinear multiple scattering paths) all calculated with the help of FEFF 8.20. Now, I found once in the FEFFIT manual the following suggestion: one might consider using several different E0's for different paths in order to improve the fit. Ok, the explanation was based on some approximations coming from FEFF code which include incomplete core-hole shielding, lack of angular variations of the valence charge distribution and charge transfer between atoms in polar materials. My question is the following: does anyone of you have some experience with such procedure? And if yes, shall than distinguish between the first shell of nearest neighbors and the rest of the atoms in terms of their E0 corrections (using 2 parameters)? Or perhaps one can use separate E0's for each path? That's one thing... The second question concerns the background correction in Artemis: I was trying to find an easy explanation of what this procedure does during the fit but I guess I'm still somewhat confused...how one can judge whether the spline co-refinement does the right job? Some people on this mailing list underline that one should avoid high correlations between fitting parameters and background parameters in order to make sure that the fit is correct. But is it the only criterion? In some of my fits background line looks kind of constant over the entire R-range which was taken into the fit. Sometimes it becomes like a modulation peaking underneath some scattering paths...even if the background parameters don't correlate significantly with fitting parameters I have my doubts whether the result is trustful. Any hints about this procedure? Well, I'll greatly appreciate any comments and feedback from all you guys. I hope I'll be able to share some of my own soon :-) Cheers, Wojciech ********************************************************************* Wojciech Gawelda Laboratoire de Spectroscopie Ultrarapide (LSU) Institut des Sciences et Ingénierie Chimiques (ISIC), Faculté des Sciences de Base (SB-BSP) Ecole Polytechnique Fédérale de Lausanne (EPFL) CH-1015 Lausanne-Dorigny, Switzerland Tel.: +41 (21) 693 0452 Fax.: +41 (21) 693 0422 E-mail: <mailto:wojciech.gawelda@epfl.ch> wojciech.gawelda(a)epfl.ch WWW: <http://lsu.epfl.ch> http://lsu.epfl.ch *********************************************************************

2 1

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 13 Dec '04

13 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 09 Dec '04

09 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