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

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. 14 Dec '04

14 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 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