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

Athena Artemis
by George Sterbinsky 12 May '11

12 May '11

Hello, I've noticed an odd behavior in Athena and Artemis and I was hoping someone could explain it to me. I've attached an Artemis file Data3.apj and an Athena file Data4.prj. First open Data3.apj. Then from the Artemis file menu choose open, then open Data4.prj and import the Data4.xmu file. Now plot the data in k-space you will see a slight difference between the two spectra, most noticeably above 15 k, so plotting in k^3 is best to see the difference. Now close Artemis and don't save. Open Data4.prj with athena and choose to import only the file Data4.xmu. Save the project as something else. I saved as Data4C.prj, which I have also attached. Close Athena and don't save. Open Data3.apj again. Then from the Artemis file menu choose open, then open Data4C.prj or whatever you may have named the file and import the Data4.xmu file, which should now be the only data file in the project. Now plot the data in k-space and you will find that the two data sets are now the same. The differences at high k are no longer present. Can anyone explain what is going on here? Thank you, George

2 3

Re: [Ifeffit] Athena Artemis
by Scott Calvin 12 May '11

12 May '11

Hi George, I've confirmed the behavior you describe on a Mac running OS 10.5.8, Artemis 0.8.014, Ifeffit 1.2.12, and Athena 0.8.061. It does seem to be a bug or a corrupted file, but I can't figure out what it's actually doing. It's not grabbing the wrong data from the Athena project--none of the other data sets look that close. It sort of seems like it imports a version with a different background subtraction (maybe a different background k-weight, for instance) when you import from the larger project. --Scott Calvin Sarah Lawrence College On May 12, 2011, at 11:18 AM, George Sterbinsky wrote: > Also, for anyone who just wants to see the difference in the two > data sets I've attached a figure. > > George > > On Thu, May 12, 2011 at 1:23 PM, George Sterbinsky <GeorgeSterbinsky(a)u.northwestern.edu > <mailto:GeorgeSterbinsky@u.northwestern.edu>> wrote: > Hello, > > I've noticed an odd behavior in Athena and Artemis and I was hoping > someone could explain it to me. > > I've attached an Artemis file Data3.apj and an Athena file Data4.prj. > > First open Data3.apj. Then from the Artemis file menu choose open, > then open Data4.prj and import the Data4.xmu file. Now plot the data > in k-space you will see a slight difference between the two spectra, > most noticeably above 15 k, so plotting in k^3 is best to see the > difference. > > Now close Artemis and don't save. Open Data4.prj with athena and > choose to import only the file Data4.xmu. Save the project as > something else. I saved as Data4C.prj, which I have also attached. > > Close Athena and don't save. Open Data3.apj again. Then from the > Artemis file menu choose open, then open Data4C.prj or whatever you > may have named the file and import the Data4.xmu file, which should > now be the only data file in the project. Now plot the data in k- > space and you will find that the two data sets are now the same. The > differences at high k are no longer present. Can anyone explain what > is going on here? > > Thank you, > George > > <DataDiff.pdf><ATT00001..txt>

1 0

Athena (linear combination fitting)
by Dilnesa, Belay 12 May '11

12 May '11

Dear Dr. Ravel, Thanks so much,for information you gave me. I subscribed already in the mailing list. I have a complex system to fit. I have a complex spectra from a hetrogenous sample and a number of reference samples. I am doing EXAFS LCF. To choose from the combinations after fitting is diffcult because the R factor of the first 5 combinations with diffrent reference combinations is similar. And as I see from my fitting the alignement plays really an important role on the LCF. You know when I made allign marked groups based on the standard, it alligns well the enregy but when I see the k-plot, it shifts. And my fitting space is on chi(k) which is sensitive when I allign. It is complex system. The procedures I am trying are, Normalization-allignement-LCF (this procedure alligns the energy well but the chi shifts and this affects my fitting because I am fitting on chi space. The other procedure i checked, Normalization-calibration-LCF (this alligns the energy good but for some spectra it shifts again). When I allign it manually by excel sheet, it works good. Can I use the following procedure...normalization, calibration-allignemet-LCF? I just found a well alligned spectra in E and K plot from this procedure. I will be happy if you comment on those procedure. Thanks so much for the keen help! With best regards, Belay

3 3

Question about transform windows and statistical parameters
by Brandon Reese 12 May '11

12 May '11

Hello everybody, I am working on fitting some EXAFS of amorphous materials and have noticed an odd (in my mind) behavior when changing transform windows. I settled on a fit using all three k-weights and the Hanning transform window obtaining statistical parameters of R=0.0018 and chi_R=361. I decided to change the transform window to a Kaiser-Bessel to see what would happen. The refined parameters came out more or less the same, well within the error bars, with the Hanning windows having slightly smaller error bars. But my statistical parameters changed significantly to R=0.0022 and chi_R=89.354. It seems that this large change may be related to why we can't use the chi_R parameter to compare fits over different k-ranges, but I am not sure about that. Have other people seen this? I would guess it means that when looking for trends in different data sets, it is more important to be consistent, rather than which specific window type is used. Thanks, Brandon

4 4

Linux command line ff2chi yields no output
by Francisco Garcia 12 May '11

12 May '11

Dear users, I was able to install iffefit on linux. From the command line I run: feff6 feff.inp This worked fine and several feffnnnn.dat files were generated. Then, I wrote an input script, tmp.iff (shortened list of paths here), for ifeffit as follows: # tmp.iff path(1, file=feff0001.dat, s02 = 0.9, sigma2 = 0 .001) path(2, file=feff0002.dat, s02 = 0.9, sigma2 = 0 .001) path(3, file=feff0003.dat, s02 = 0.9, sigma2 = 0 .001) path(4, file=feff0004.dat, s02 = 0.9, sigma2 = 0 .001) path(5, file=feff0005.dat, s02 = 0.9, sigma2 = 0 .001) path(6, file=feff0006.dat, s02 = 0.9, sigma2 = 0 .001) path(7, file=feff0007.dat, s02 = 0.9, sigma2 = 0 .001) path(8, file=feff0008.dat, s02 = 0.9, sigma2 = 0 .001) path(9, file=feff0009.dat, s02 = 0.9, sigma2 = 0 .001) path(10, file=feff0010.dat, s02 = 0.9, sigma2 = 0 .001) path(11, file=feff0011.dat, s02 = 0.9, sigma2 = 0 .001) ff2chi(1-11, group=mycalc) fftf(mycalc.chi, kmin=1, kmax=15, dk=0.5, kweight=2.0, kwindow='hanning') # My aim here is to sum the paths to generate chi(k). Now if I run the following command: ifeffit -x tmp.iff the following output is printed on the screen: reading feff0101.dat reading feff0102.dat reading feff0103.dat reading feff0104.dat reading feff0105.dat reading feff0106.dat reading feff0107.dat reading feff0108.dat reading feff0109.dat reading feff0001.dat reading feff0002.dat reading feff0003.dat reading feff0004.dat reading feff0005.dat reading feff0006.dat reading feff0007.dat reading feff0008.dat reading feff0009.dat reading feff0010.dat reading feff0011.dat It appears that the feffnnnn.dat files were read successfully. However, no mycalc.chi output was produced by ff2chi() [and therefore no mycalc.chir_* output was produced by fftf()]. I don't know if my approach is missing an important step or my entire procedure is nonsensical. Thanks a lot!

5 4

Re: [Ifeffit] EXAFS
by Scott Calvin 11 May '11

11 May '11

Hi Francisco, I'll take a shot at some of these questions--I'm sure others will chime in as well. On May 11, 2011, at 2:34 PM, Francisco Garcia wrote: > Dear all, > > I tried computing K-edge chi(k) for a solvated metal ion. For each > snapshot, I simply carved out a cluster of radius 6 Ang around the > metal. > > 1. if I set RMAX to say 5.5 in feff.inp, the chi(k) plot looks totally > different from the case where the RMAX line is commented out > (particularly k>10). I thought RMAX is the largest metal-H or metal-O > separation but I think I am wrong > RMAX is the longest half-path length to include in chi(k). For direct scattering paths, it is therefore the most distant scattering pair that is allowed to contribute. So your understanding of the meaning is essentially correct. In FEFF7, the documentation says it defaults to 2.2 times the nearest neighbor if it is not included. So commenting out RMAX does not mean to include all paths! That could be responsible for a considerable difference in chi(k). > 2. I dont quite understand why the number of paths increases > (sometimes by a factor of 3) when I set RMAX as opposed to the case > where I comment it out. See above. If your nearest neighbor is at, say, 1.8 angstroms, then commenting out RMAX is equivalent to setting it to 3.96 angstroms. That's much less than 5.5, and explains the smaller number of paths. > > 3. From time to time I get warnings indicating that a water O-H > distance is too short: > > WARNING: TWO ATOMS VERY CLOSE TOGETHER. CHECK INPUT. > atoms 5 7 > 5 0.14400 2.09700 1.16300 > 7 0.77400 2.67400 1.00800 > > I tried setting FOLP to 0.8 for H but the warnings persist. Don't worry about it. This FEFF warning doesn't really expect hydrogens, and so sometimes gives a warning for atoms that would be close if they were anything bigger, but are OK if one is a hydrogen. Looking at the coordinates it specifies in your example, the two atoms are about 1 angstrom apart--OK if one is a proton. > > 4. On what criteria are sigma2 and s02 chosen? They are not usually > reported in published theoretical papers and I was wondering if they > are arbitrary. FEFF is not usually used for EXAFS on its own. Most people use a fitting program, such as Ifeffit, to optimize the values of S02 and sigma2 to provide the best fit. (Although S02 in particular is often fit for a known material, and then that value used.) When used in that way, FEFF should be run with S02 = 1 and sigma2 = 0 to avoid confusion. > > 5. Finally, is the chi(k) dependent of which version of FEFF is being > used. I am asking this because the peak height of my FEFF6 chi(k) is > slightly lower than that of published results using FEFF8. > Yes, they are slightly different. For EXAFS, they probably aren't different enough to affect the answers to your scientific questions much, though. --Scott Calvin Sarah Lawrence College

1 0

EXAFS
by Francisco Garcia 11 May '11

11 May '11

Dear all, I tried computing K-edge chi(k) for a solvated metal ion. For each snapshot, I simply carved out a cluster of radius 6 Ang around the metal. 1. if I set RMAX to say 5.5 in feff.inp, the chi(k) plot looks totally different from the case where the RMAX line is commented out (particularly k>10). I thought RMAX is the largest metal-H or metal-O separation but I think I am wrong 2. I dont quite understand why the number of paths increases (sometimes by a factor of 3) when I set RMAX as opposed to the case where I comment it out. 3. From time to time I get warnings indicating that a water O-H distance is too short: WARNING: TWO ATOMS VERY CLOSE TOGETHER. CHECK INPUT. atoms 5 7 5 0.14400 2.09700 1.16300 7 0.77400 2.67400 1.00800 I tried setting FOLP to 0.8 for H but the warnings persist. 4. On what criteria are sigma2 and s02 chosen? They are not usually reported in published theoretical papers and I was wondering if they are arbitrary. 5. Finally, is the chi(k) dependent of which version of FEFF is being used. I am asking this because the peak height of my FEFF6 chi(k) is slightly lower than that of published results using FEFF8. Thanks

1 0

Re: [Ifeffit] Question about transform windows and statistical parameters
by Scott Calvin 11 May '11

11 May '11

Hi Brandon, I don't find this terribly surprising. First, a little background which you may or may not know: Reduced chi-square is a statistical parameter which requires a knowledge of the uncertainty of the measurement to compute. In theory, therefore, it "knows" that a "good" fit to noisy data will not be as close in an absolute sense as a "good" fit to high-quality data. The problem, however, is that it's difficult to know what is the proper quantity to use for the uncertainty of the measurement in EXAFS analysis. One could use the standard deviation of subsequent scans, but that is only sensitive to random scan-to-scan error. Something like, say, a monochromator glitch is quite reproducible, and yet most of us would consider it to be part of the measurement error. So the default behavior of Ifeffit is to look at the Fourier transform between 15 and 25 angstroms, and figure that any amplitude there is due to error of some kind, and not signal. It then makes the assumption that the same amount of error is present in the range being fit (i.e. the error is "white"), and from there computes the reduced chi-square. This is in some sense a dubious procedure, but the real problem is that we don't have a good method for estimating the measurement uncertainty, so we have to do something. As long as we are comparing fits to exactly the same data, on the same k-range, with the same k-weight, with the same windows, then changes in reduced chi-square are worth looking at. If all you've done is change a constraint or change the R-range being fit, for instance, a lower reduced chi-square is a good sign (use the Hamilton test if you want to be rigorous about it.) But change the k-range, or the k-weight, or the window, or the data, and Ifeffit's estimate of the uncertainty can change wildly, causing a correspondingly wild change in reduced chi-square. After all, one glitch toward the end of the k-range you are thinking can introduce a lot of high-R amplitude in to the Fourier transform, and different windows would treat it very differently. But single-point glitches often don't have much effect on the results of your fit, precisely because they do affect the high-R part of the Fourier transform much more than low-R part. Ifeffit's default behavior can be overridden, if you so choose. The parameter "epsilon" (available on the Data panel of Artemis) overrides Ifeffit's usual estimate for uncertainty. So in your case, I suggest putting a number--any number--in for epsilon, and then comparing fits using the two windows. Probably you will find that the reduced chi- squares become much more similar to each other. Incidentally, while in this case the default behavior of Ifeffit is merely distracting, there is a circumstance where it can be a more substantial problem: mutliple data-set fits (e.g. on multiple edges of the same sample). If Ifeffit finds uncertainties for the different data sets that are quite different from each other because, for instance, of the presence of a glitch in one, it will in effect weight the data very differently when doing a fit. In multiple-data set fits, therefore, it is often advisable to come up with your own scheme for setting epsilons (perhaps inversely proportional to the edge jump of the set, or something like that), to avoid wonky weightings. --Scott Calvin Sarah Lawrence College On May 11, 2011, at 12:47 PM, Brandon Reese wrote: > Hello everybody, > > I am working on fitting some EXAFS of amorphous materials and have > noticed an odd (in my mind) behavior when changing transform > windows. I settled on a fit using all three k-weights and the > Hanning transform window obtaining statistical parameters of > R=0.0018 and chi_R=361. I decided to change the transform window to > a Kaiser-Bessel to see what would happen. The refined parameters > came out more or less the same, well within the error bars, with the > Hanning windows having slightly smaller error bars. But my > statistical parameters changed significantly to R=0.0022 and > chi_R=89.354. It seems that this large change may be related to why > we can't use the chi_R parameter to compare fits over different k- > ranges, but I am not sure about that. Have other people seen this? > I would guess it means that when looking for trends in different > data sets, it is more important to be consistent, rather than which > specific window type is used. > > Thanks, > Brandon > <ATT00001..txt>

1 0

What does FEFF stand for?
by Francisco Garcia 10 May '11

10 May '11

Dear all, I wish to ask a somewhat novice question: What does the acronym FEFF stand for? Thank you.

3 2

Re: [Ifeffit] What does FEFF stand for?
by Scott Calvin 10 May '11

10 May '11

I looked into this a bit further, Bruce, and I'd tentatively say the curved-wave corrections do turn out to be the source of the "eff": The earliest use of f_eff I can find is from a 1986 Phys. Rev. B article entitled "Spherical-wave effects in photoelectron diffraction," by Sagurton et al. (John Rehr is also in the author list). It says "an approximaton for including SW [spherical wave] corrections suggested recently by Rehr, Albers, and Natoli has been incorporated in some of our calculations...the net limiting result is a calculation procedure in which an effective scattering factor f_eff,j(r,theta_j) which depends on r takes the place of the usual PW [plane wave] f_j(theta_j)." In addition, was FEFF3 a multiple-scattering code? The comments in its header and the 1991 JACS article on it mention only single-scattering. It would make an extraordinary amount of sense that the "eff" would refer to FEFF's ability to handle multiple-scattering paths, but I don't think that's the actual historical origin of the terminology. And as for Anatoly's suggestion, I'll, uh, leave that one be for the moment. --Scott Calvin Sarah Lawrence College On May 10, 2011, at 12:17 PM, Bruce Ravel wrote: > On Tuesday, May 10, 2011 03:03:23 pm Scott Calvin wrote: >> My understanding, although I could be wrong is that the "effective" >> part came from an improvement of the theory to account for curved- >> wave >> effects. In other words, early theories approximated the >> photoelectron >> as a plane wave, but of course it spreads out radially from the >> absorbing atom. That change necessitated tweaking the definitions of >> the factors, so it became the "effective" f. > > I think you are mistaken. My memory of the etymology has to do with > the formalism dating back to Feff5 for computing MS paths. > > For a purely single scattering theory, you have an F and a phi > (without the subscript eff). That is, you can simply compute the > scatting function for the one scatterer and be done with it. > > Feff's path expansion introduced two clever things to the EXAFS > business. One is that it provided a formalism for computing a single > function that takes into account the angle-dependent scattering > functions of all atoms in an arbitrary-geometry multiple scattering > path. This allows one to treat a MS path with the familiar SS EXAFS > equation only by replacing F and phi with F_eff and phi_eff. That > innovation is central to how Ifeffit works. > > The second clever thing is that it's really fast. That's not such a > big deal today, but back in the mid-90s, when a Feff run could take > several minutes, a faster algorithm was very welcome indeed. > > B > >

1 0