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

Re: Generating single scattering paths in Artemis
by Webb, Samuel M. 06 Jan '05

06 Jan '05

Hi all... I know that this isn't necessarily an Artemis solution, but there is an option/module in SIXPACK (that other IFEFFIT interface) to do just what you've been asking about -- create simple single scattering paths between two atoms in a variety of coordination environments (tetrahedral, octahedral, etc). It has a nice periodic table interface to boot. I use it occasionally to do some quick and dirty fitting -- I do agree with Scott that its not always the most accurate way to go about things. The resulting FEFF file is placed in a FEFF folder in the sixpack root directory. Hope that helps some. Sam

1 0

RE: [Ifeffit] Generating single scattering paths in Artemis
by Barton, David (DG) 05 Jan '05

05 Jan '05

Scott, > This can be fixed by editing the feff.inp file to remove the > Fe potential 1, but that's not enough--the oxygen scatterers > then have to have their potential renumbered to 1 to make > things work. That's a lot of work to do what should be simple. > > So I vote for changing the way Artemis works in such > circumstances so that less editing is needed: if the > absorbing atom is not present in the scattering list, then it > shouldn't have a second entry in the potential list. > I second this vote, since I also have had this same problem. New users could become quickly disgruntled by the Fatal Error message when attempting to put in simple systems or just by choosing a short cluster distance to only include the first shell in the FEFF calculation. At a minimum, it would be nice if Artemis trapped this error and reported a more friendly popup error message. Dave _________________________________ David Barton, PhD. The Dow Chemical Company Catalysis R&D

1 0

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