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

Can Artemis Simulate a FT spectrum?
by Palomino, Robert 19 May '11

19 May '11

Hi, I was wondering if it was possible for Artemis to simulate a FT spectrum, I have a model and would like to visually see what the simple R-space spectrum would like so see if there are any similarites at all to my sample. I'm not sure if the reason it doesn't converge is because the signal level is too low or if it is the wrong model all together. Robert

2 1

Athena (Question about LC fitting)
by Yu-Ting Liu 15 May '11

15 May '11

Hi, Related to this issue, I have a question about whether alignment is necessary for LCF when the oxidation state among sample and standards is different. I used to align spectra of samples and standards before LCF while handling P. However, I got confused about Se. For Se speciation, I prepared six Se species with oxidation state of -2 (FeSe), 0 (elemental Se), 0 (seleno-cystine), 0 (seleno-methionine), 4 (selenite), and 6 (selenate) to fit samples collected from sediments and biofilms. I am wondering whether the shift of spectra due to the alignment would make standards mis-fit spectral features of samples. Thank you so much for the help! Yu-Ting Liu Yu-Ting (Lusia) Liu Postdoctoral Associate Duke University Civil and Environmental Engineering Durham, NC, 27708-0287 ------------------------------------------------------------------------------- Belay, I am CCing my response to the Ifeffit Mailing List, which is the appropriate venue for questions about the use fo the software. I encourage you to subscribe to and use the mailing list. On Tuesday, May 10, 2011 08:50:10 am you wrote: > Dear Dr. Ravel, > I am doing my PhD in title with identication of Fe-phases in cement > hydrates. I am using Athena for LC fitting. I use EXAFS spectra for the > fittings. My question is before LC fitting of EXAFS spectra , do I need to > calibrate the energy? I have normlized and alligned the spectra very well. > The problem is data calibration, when I calibrate the spectra, the energy > shifts and it destroys the fitting. Can you please give a clue why this > happens or do I make a mistake on the procedure? Thanks so much for your > cooperation. Alignment puts a group of spectra on the same relative energy scale. It is often necessary to do an explicit alignment when working at a beamline with an unstable and unencoded monochromator, as might be found at some older beamlines. Calibration intends to put a single spectrum on the correct absolute energy scale. That is, if you know what point in a spectrum represents a particular absolute energy, then calibration does as I said. LCF requires that the ensemble of data and standards all be aligned -- i.e. put on the same relative energy axis. Once that is done, you can proceed with LCF analysis. LCF does not require that the data be calibrated, only that they be aligned. That is, LCF requires that all the data+standards be on the same relative energy axis, but does not require that that energy axis be calibrated. The reason that is so is because LCF fitting is an abstract, numerical function that treats one data set (the "data") as a linear combination of two or more other data sets (the "standards"). No part of that mathematical process requires knowledge of the species of the absorber atom. Indeed, LCF does not require that the x-axis represent energy, only that it be the same for all data+standards. That said, the interpretation of your data might be easier to consider and easier to present in publcation if your data is calibrated. For instance, the Xray Data Booklet tells us that copper metal has an edge at 8979 eV. Calibration is the process of transforming your data such that its edge does, in fact, happen at 8979 eV. In Athena, using the calibration dialog both does an energy shift and sets the E0 value to 8979. If you want to calibrate your data as well as aligning your data, I find it less confusing to do the calibration first. I believe that the procedures can be commutative, but calibrating after aligning is confusing to me and more prone to error for me. Someone else might give you different advice. Finally, remember that calibration requires actual knowledge (as opposed to some assumption) about what point in a spectrum represents a particular absolute energy value. While you might reasonably assign the first big peak in the first derivative of copper metal to 8979 eV, you cannot correctly assign the first big peak in the first derivative of copper oxide to 8979 eV due to the upwards shift in threshold energy in the oxide. HTH, B

2 2

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

13 May '11

Matt, On May 13, 2011, at 8:39 AM, Matt Newville wrote: >> >> After all, the epsilon should be different for different k-ranges, >> as your signal to noise ratio probably changes as a function of k. >> Using the same epsilon doesn't reflect that. > > Without seeing the data in question, this seems like speculation to > me. I'm not at all sure why epsilon (the variation in chi(k)) > should depend strongly on the k-range. In my experience, it usually > does not. The S/N ratio will surely change with k, but that would > surely be dominated by the rapid decay in |chi(k)|, rather than a > change in epsilon. I'm confused. We Fourier transform k-weighted data. Since Ifeffit uses the high-R amplitude to estimate uncertainty, it seems to me that what matters is signal-to-noise, not just noise in the original unweighted chi(k). Am I wrong in that? I may be misunderstanding how epsilon_r is calculated. And epsilon_r is the relevant epsilon for a fit in R space, right? > > I think your assumption that epsilon will depend strongly on k may > not correct. Do you have evidence for this? I would say that it > is not strongly dependent on k, and that reduced chi-square is > useful in comparing fits with different k-ranges. I just tried it on the FeC2O4 chi(k) attached to this post. It's a good example of data where it's not immediately clear to me what the "best" value for kmax is, so it would be tempting to use RCS to compare fits over different k-ranges. I used k-weight 3, and Hanning windows with dk = 1. I chose kmin as 2 and stepped kmax by 0.5, recording epsilon_r for each: kmax epsilon_r 7 0.034840105 7.5 0.041843848 8 0.082627337 8.5 0.087550367 9 0.086032007 9.5 0.085996216 10 0.088679339 10.5 0.090364699 11 0.092509939 11.5 0.108103081 There's a general trend of increasing epsilon_r with an increase in k. There's also a jump of a factor of 2 between 7.5 and 8. Why? Because there's a glitch there, and the glitch adds high-R structure. To make sure there wasn't something odd about this particular chi(k), I took one of the data sets included with the horae distribution: the file y300.chi in the ybco folder. I followed the same procedure as before, except I stepped by 1 inverse angstrom each time, because of the greater data range. kmax epsilon_r 7 0.012866125 8 0.073383695 9 0.078255772 10 0.080016040 11 0.091634572 12 0.105419473 13 0.164341701 14 0.195266957 15 0.224727593 16 0.411139882 17 0.480293296 If anything, the trend is more clear here. > > I find it confusing that you expect the noise in the data to depend > (strongly, even) on k, but not on R. The general wisdom is the > estimate of epsilon from the high-R components is too low, > suggesting that the R dependence is significant. Every time I've > looked, I come to the conclusion that noise in data is either > consistent with "white" or so small as to be difficult to measure. > I believe Corwin Booth's recent work supports the conventional > wisdom that epsilon decreases with R, but I don't recall it > suggesting a significant k dependence. I'm not making any claims as to whether, in general, the noise in the data depends on R. I can speculate about circumstances where low R noise is greater (due, for instance, to temperature fluctuations in cooling water, which are likely to be fairly slow), or where high R noise is greater (an example here would be if whatever system is keeping the beam on the sample vertically as the mono scans is tending to overshoot). But Ifeffit's estimation of epsilon_r demonstrably does not depend on the R-range used for fitting, regardless of the distribution of noise in R. That's a very different thing. Thus, changing the R-range of a fit is completely safe as far as comparing RCS goes. --Scott Calvin Sarah Lawrence College

2 1

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

13 May '11

Hi Brandon, Matt and Bruce both gave good, thorough answers to your questions this morning. Nevertheless, I'm going to chime in too, because there are some aspects of this issue I'd like to put emphasis on. On May 11, 2011, at 8:46 PM, Brandon Reese wrote: > I tried your suggestion with epsilon and the chi-square values came > out to be very similar values with the different windows. Does this > mean that reporting reduced chi-square values in a paper that > compared several data sets would not be necessary and/or appropriate? Bruce said "no" emphatically, and I say "yes," but I think we've understood the question differently. As Bruce says: > Of course, reduced chi-square can only be compared for fitting > models which compute epsilon the same way or use the same value for > epsilon. That's the key point. I've gotten away from reporting values for reduced chi-square (RCS). That's a personal choice, and is not in accord with the International X-Ray Absorption Society's Error Reporting Recommendation, available here: http://ixs.iit.edu/subcommittee_reports/sc/ I think the difficulty in choosing epsilon is more likely to make a reduced chi-square number confusing than enlightening. But I am moving increasingly toward reporting changes in reduced chi-square between fits on the same data, and applying Hamilton's test to determine if improvements are statistically significant. > Would setting a value for epsilon allow comparisons across > different k-ranges, different (but similar) data sets, or a > combination of the two using the chi-square parameter? > Maybe not. After all, the epsilon should be different for different k- ranges, as your signal to noise ratio probably changes as a function of k. Using the same epsilon doesn't reflect that. > > > In playing around with different windows and dk values my fit > variables generally stayed within the error bars, but the size of > the error bars could change more than a factor 2. Does this mean > that it would make sense to find a window/dk that seems to "work" > for a given group of data and stay consistent when analyzing that > data group? The fact that your variables stay within the error bars is good news. The change in the size of the error bars may be related to a less-than- ideal value for dk you may have used for the Kaiser-Bessel window. But yes, find a window and dk combination that seems to work well and then stay consistent for that analysis. Unless the data is particularly problematic, I'd prefer making a reasoned choice before beginning to fit and then sticking with it; a posteriori choices for that kind of thing make me a little nervous. * * * At the risk of being redundant, four quick examples. Example 1: You change the range of R values in the Fourier transform over which you are fitting a data set. For this example, RCS is a valuable statistic for letting you know whether the fit supports the change in R-range. Example 2: You change the range of k values over which you are fitting your data. For this example, comparing RCS is unlikely to be useful. You are likely trying different k-ranges because you are suspicious about some of the data at the extremes of your range. Including or excluding that data likely implies epsilon should be changed, but by how much? Thus the unreliability of comparing RCS in this case. Example 3: You change constraints on a fit on the same data range. For this example, comparing RCS is very useful. Example 4: You compare fits on the same data range, with the same model, on two different data sets which were collected during the same synchrotron run under similar conditions. For this example, proceed with caution. You may decide to trust Ifeffit's method for estimating epsilon, or you may be able to come up with your own (perhaps basing it on the size of the edge jumps). Hopefully issues like glitches and high-frequency jitter are nearly the same for both samples, which gives you a fighting chance of making reasonable estimates of epsilon. Done with a little care, there may be value in comparing RCS for this kind of case. --Scott Calvin Sarah Lawrence College

3 2

more bugs in atoms?
by Gudrun Lisa Bovenkamp 12 May '11

12 May '11

Hey everybody, For a while I was wondering why I could not get a proper XANES simulation using FEFF (8 or 9). Recently I realized that the xyz list which is created in atoms from the crystal structure is not the same as from a crystal structure program for PbSO4. Can somebody please check this. I attached my feff.imp file including the atoms.imp (which was created by arthemis). Thanks, Lisa * input file was generated by Artemis 0.8.014 * Atoms written by and copyright (c) Bruce Ravel, 1998-2001 * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * * total mu*x=1: 13.94 microns, unit edge step: 24.69 microns * specific gravity = 5.382 * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * * Normalization correction: 0.00039 ang^2 * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * * ----------------------------------------------------------------- * The following crystallographic data were used: * * title *-PbSO4 -[PNMA] Anglesite - orthorhombic * title 'James, R W' * title Proceedings of the Royal Society of London, Series A: Mathematical and Physical Sciences (76,1906-) * space = P n m a * a = 8.450 b = 5.380 c = 6.930 * alpha = 90.0 beta = 90.0 gamma = 90.0 * core = Pb edge = L3 * atoms * ! elem x y z tag occ * Pb 0.31530 0.25000 0.33750 1.00000 * S 0.44300 0.25000 -0.19470 1.00000 * O -1.00000 -1.00000 -1.00000 1.00000 * ----------------------------------------------------------------- EDGE L3 S02 1.0 CONTROL 1 1 1 1 1 1 PRINT 1 0 0 0 0 0 SCF 5.16556 0 15 0.1 EXCHANGE 0 0 0 XANES 6.0 0.07 0.5 FMS 6 *LDOS -20 20 0.1 POTENTIALS * ipot z [ label l_scmt l_fms stoichiometry ] 0 82 Pb -1 -1 0 1 8 O -1 -1 1 2 16 S -1 -1 1 3 82 Pb -1 -1 1 ATOMS * this list contains 156 atoms * x y z ipot tag distance 0.00000 0.00000 0.00000 0 Pb 0.00000 1.56072 1.34500 1.12613 3 O_1 2.34799 1.56072 -1.34500 1.12613 3 O_1 2.34799 1.07906 0.00000 3.24185 2 S_1 3.41672 -2.18263 2.69000 -0.22315 2 S_2 3.47128 -2.18263 -2.69000 -0.22315 2 S_2 3.47128 2.04237 2.69000 -0.98960 2 S_3 3.51947 2.04237 -2.69000 -0.98960 2 S_3 3.51947 -2.66429 1.34500 -2.33887 3 O_2 3.79180 -2.66429 -1.34500 -2.33887 3 O_2 3.79180 1.07906 0.00000 -3.68815 2 S_4 3.84276 -3.14594 0.00000 2.47540 2 S_5 4.00307 4.22500 0.00000 -1.21275 1 Pb_1 4.39561 -4.22500 0.00000 -1.21275 1 Pb_1 4.39561 1.56072 4.03500 1.12613 3 O_3 4.47049 1.56072 -4.03500 1.12613 3 O_3 4.47049 -1.10357 2.69000 3.46500 1 Pb_2 4.52329 -1.10357 -2.69000 3.46500 1 Pb_2 4.52329 -1.10357 2.69000 -3.46500 1 Pb_2 4.52329 -1.10357 -2.69000 -3.46500 1 Pb_2 4.52329 3.12143 2.69000 2.25225 1 Pb_3 4.69596 3.12143 -2.69000 2.25225 1 Pb_3 4.69596 -2.66429 4.03500 -2.33887 3 O_4 5.37122 -2.66429 -4.03500 -2.33887 3 O_4 5.37122 0.00000 5.38000 0.00000 1 Pb_4 5.38000 0.00000 -5.38000 0.00000 1 Pb_4 5.38000 -3.14594 0.00000 -4.45460 2 S_6 5.45348 -2.66429 1.34500 4.59112 3 O_5 5.47593 -2.66429 -1.34500 4.59112 3 O_5 5.47593 5.30406 0.00000 2.47540 2 S_7 5.85326 1.56072 1.34500 -5.80387 3 O_6 6.15872 1.56072 -1.34500 -5.80387 3 O_6 6.15872 3.12143 2.69000 -4.67775 1 Pb_5 6.23384 3.12143 -2.69000 -4.67775 1 Pb_5 6.23384 1.07906 5.38000 3.24185 2 S_8 6.37325 1.07906 -5.38000 3.24185 2 S_8 6.37325 -5.32857 2.69000 2.25225 1 Pb_6 6.37984 -5.32857 -2.69000 2.25225 1 Pb_6 6.37984 5.78571 1.34500 -2.33887 3 O_7 6.38387 5.78571 -1.34500 -2.33887 3 O_7 6.38387 1.07906 5.38000 -3.68815 2 S_9 6.61145 1.07906 -5.38000 -3.68815 2 S_9 6.61145 -2.66429 4.03500 4.59112 3 O_8 6.66769 -2.66429 -4.03500 4.59112 3 O_8 6.66769 -3.14594 5.38000 2.47540 2 S_10 6.70589 -3.14594 -5.38000 2.47540 2 S_10 6.70589 6.26736 2.69000 -0.22315 2 S_11 6.82391 6.26736 -2.69000 -0.22315 2 S_11 6.82391 2.04237 2.69000 5.94040 2 S_12 6.83343 2.04237 -2.69000 5.94040 2 S_12 6.83343 5.30406 0.00000 -4.45460 2 S_13 6.92651 0.00000 0.00000 6.93000 1 Pb_7 6.93000 0.00000 0.00000 -6.93000 1 Pb_7 6.93000 4.22500 5.38000 -1.21275 1 Pb_8 6.94736 -4.22500 5.38000 -1.21275 1 Pb_8 6.94736 4.22500 -5.38000 -1.21275 1 Pb_8 6.94736 -4.22500 -5.38000 -1.21275 1 Pb_8 6.94736 1.56072 6.72500 1.12613 3 O_9 6.99497 1.56072 -6.72500 1.12613 3 O_9 6.99497 -6.40764 2.69000 -0.98960 2 S_14 7.01949 -6.40764 -2.69000 -0.98960 2 S_14 7.01949 4.22500 0.00000 5.71725 1 Pb_9 7.10898 -4.22500 0.00000 5.71725 1 Pb_9 7.1089 END

2 1

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