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

Temp effect
by Hana 17 Jun '11

17 Jun '11

Dear EXAFS experts, I am quite a beginner, and that's might be an ignorant question but really important to my work, so I would be happy to get a direction: what would be the right way to weigh in the effect of temperature in soils samples, since solutions like Debye models will not fit to my understanding? specifically, I am trying to compare my measurements(collected at 10K) to literature data of these metals adsorbed on iron oxides (collected at room temperature). I would appreciate any advise, Hana

3 2

Re: [Ifeffit] McMaster correction
by Scott Calvin 17 Jun '11

17 Jun '11

I apologize if I have abused the list while working on my text. I will find a different channel for raising these questions and requests once the current discussion is complete. --Scott On Jun 16, 2011, at 8:11 PM, Matt Newville wrote: > Hope that helps. I have to admit I'm a little uneasy with the > frequency of "I've been pondering..." discussion topics alternating > with requests to review book chapters, and find myself being more > cautious in my response than I would if someone was actually asking a > question. On the other hand, I don't think anyone would object if > you added a button to Athena that normalized the data in a way that > included a correction for the expected decay of mu(E).

2 1

Re: [Ifeffit] McMaster correction
by Scott Calvin 17 Jun '11

17 Jun '11

Thanks, all! Here's what I got out of the discussion: FEFF is calculating the "correct" chi(k), and applying an approximate correction introduces additional sources of error. But the only way to measure chi(k) is to extract it from unnormalized data, and the original definition of chi was an arbitrary, if sensible, one: chi(E) = mu(E)/mu_o(E) - 1. And mu_o(E), while not known with great accuracy, depends only on the element and the edge (perhaps excepting minor contributions from AXAFS). Not applying a correction, whether McMaster or something more accurate (such as the ones Anatoly and John suggested), is equivalent to using the approximation mu_o(E) = mu_o(E_o), which is less accurate than the alternatives. On the other hand, the effect is almost entirely a shift in the absolute (as opposed to relative) value of sigma^2. Considering that, it seems to me that this would be a good option for Athena when calculating chi(k). (I think it would be more problematic to apply when calculating normalized energy-space data, as in that case the correction would depend on instrumental effects and the absorption of other edges in the sample.) So, Bruce, I guess this was first a discussion and then a feature request. :) --Scott Calvin Sarah Lawrence College On Jun 17, 2011, at 4:14 AM, John J. Rehr wrote: > Hi Scott et al., > > Thanks for bringing up this issue. Whether or not McMaster > corrections > are useful does seem to depend on details of the measurement. But > my question is: for the cases where they are useful, can one do > better? As the data & theory get better and better, perhaps we > should try > to extract more accurate cross sections mu(E). For example, is it at > all > of interest to have embedded atom cross-sections to replace the atomic > based Cromer-Liberman cross sections or empirical tables? > > John > > > On Thu, 16 Jun 2011, Scott Calvin wrote: > >> Hi all, >> I've been pondering the McMaster correction recently. >> >> My understanding is that it is a correction because while chi(k) is >> defined >> relative to the embedded-atom background mu_o(E), we almost always >> extract >> it from our data by normalizing by the edge step. Since mu_o(E) drops >> gradually above the edge, the normalization procedure results in >> oscillations that are too small well above edge, which the McMaster >> correction then compensates for. It's also my understanding that this >> correction is the same whether the data is measured in absorption or >> fluorescence, because in this context mu_o(E) refers only to >> absorption due >> to the edge of interest, which is a characteristic of the atom in >> its local >> environment and is thus independent of measurement mode. >> >> So here's my question: why is existing software structured so that >> we have >> to put this factor in by hand? Feff, for instance, could simply >> define >> chi(k) consistently with the usual procedure, so that it was >> normalized by >> the edge step rather than mu_o(E). A card could be set to turn that >> off if a >> user desired. Alternatively, a correction could be done to the >> experimental >> data by Athena, or automatically within the fitting procedure by >> Ifeffit. >> >> Of course, having more than one of those options could cause >> trouble, just >> as the ability to put sigma2 into a feff calculation and in to >> Ifeffit >> sometimes does now. But wouldn't it make sense to have it available >> (perhaps >> even the default) at one of those stages? >> >> --Scott Calvin >> Sarah Lawrence College

1 0

McMaster correction
by Scott Calvin 17 Jun '11

17 Jun '11

Hi all, I've been pondering the McMaster correction recently. My understanding is that it is a correction because while chi(k) is defined relative to the embedded-atom background mu_o(E), we almost always extract it from our data by normalizing by the edge step. Since mu_o(E) drops gradually above the edge, the normalization procedure results in oscillations that are too small well above edge, which the McMaster correction then compensates for. It's also my understanding that this correction is the same whether the data is measured in absorption or fluorescence, because in this context mu_o(E) refers only to absorption due to the edge of interest, which is a characteristic of the atom in its local environment and is thus independent of measurement mode. So here's my question: why is existing software structured so that we have to put this factor in by hand? Feff, for instance, could simply define chi(k) consistently with the usual procedure, so that it was normalized by the edge step rather than mu_o(E). A card could be set to turn that off if a user desired. Alternatively, a correction could be done to the experimental data by Athena, or automatically within the fitting procedure by Ifeffit. Of course, having more than one of those options could cause trouble, just as the ability to put sigma2 into a feff calculation and in to Ifeffit sometimes does now. But wouldn't it make sense to have it available (perhaps even the default) at one of those stages? --Scott Calvin Sarah Lawrence College

5 4

EXAFS modules
by Joshua Kas 14 Jun '11

14 Jun '11

Hi Francisco, This depends on which version of FEFF you are using. The following shows the executables needed for EXAFS in feff9 and feff8. The names are different, so I have put the corresponding module in parentheses. FEFF9 FEFF8 rdinp rdinp atomic ffmod1 (atomic and pot) pot ffmod2 (xsph) xsph ffmod4 (path) path ffmod5 (genfmt) genfmt ffmod6 (ff2x) ff2x Cheers, Josh Kas > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 13 Jun 2011 12:22:16 -0700 > From: Francisco Garcia <garcia.ff.000(a)gmail.com> > To: ifeffit(a)millenia.cars.aps.anl.gov > Subject: [Ifeffit] EXAFS modules > Message-ID: <BANLkTimTXXPzOh-sFoYaq_kE3v0pq4BAYA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Dear users, > > Which of the following modules are needed to compute only the EXAFS > spectra (that is, chi.dat)?: > > ipot > ixsph > ifms > ipaths > igenfmt > iff2x > > Thank you. > > > ------------------------------ > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest, Vol 100, Issue 9 > *************************************** >

1 0

EXAFS modules
by Francisco Garcia 13 Jun '11

13 Jun '11

Dear users, Which of the following modules are needed to compute only the EXAFS spectra (that is, chi.dat)?: ipot ixsph ifms ipaths igenfmt iff2x Thank you.

1 0

Fe foil at 900 C
by KONG Quingyu 12 Jun '11

12 Jun '11

Hello, We are measuring the kinetic of carbon nanotubes using Fe as catalytic element. To analyze the data, we need the Gamma iron (Fe fcc, iron foil measured with a temperature between 910 and 1400 C) EXAFS spectrum. We appreciate if anyone could send us this spectrum. Thanks a lot in advance, Sincerely Qingyu Kong Beamline ODE Société civile Synchrotron SOLEIL L'Orme des Merisiers Saint-Aubin - BP 48 91192 GIF-sur-YVETTE CEDEX Tel: +33 (0)1 69 35 97 84 (office) +33 (0)1 69 35 97 16 (beamline) email: kong(a)synchrotron-soleil.fr ________________________________________ From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [ifeffit-bounces(a)millenia.cars.aps.anl.gov] on behalf of ifeffit-request(a)millenia.cars.aps.anl.gov [ifeffit-request(a)millenia.cars.aps.anl.gov] Sent: Wednesday, June 08, 2011 9:03 AM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: Ifeffit Digest, Vol 100, Issue 6 Send Ifeffit mailing list submissions to ifeffit(a)millenia.cars.aps.anl.gov To subscribe or unsubscribe via the World Wide Web, visit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit or, via email, send a message with subject or body 'help' to ifeffit-request(a)millenia.cars.aps.anl.gov You can reach the person managing the list at ifeffit-owner(a)millenia.cars.aps.anl.gov When replying, please edit your Subject line so it is more specific than "Re: Contents of Ifeffit digest..." Today's Topics: 1. Re: Question about shift in E0 (Christopher Patridge) 2. Re: Question about shift in E0 (Brandon Reese) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Jun 2011 21:55:25 -0400 From: Christopher Patridge <patridge(a)buffalo.edu> To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Subject: Re: [Ifeffit] Question about shift in E0 Message-ID: <D53A5E8D-B912-4E7B-A567-2E0BB79B4B06(a)buffalo.edu> Content-Type: text/plain; charset="us-ascii" Brandon, I have a question about your method. You mention that you pick E0 based on the 1st peak of the derivative for each sample then extract chi(k). Have you tried constraining E0 across the set? I have thought that in order to make a good comparison between samples in a set, a common E0 should be chosen in order to replicate closely the background function across the whole set. Constraining may also provide a trend in the fitting. Buena salud, Chris On Jun 6, 2011, at 6:46 PM, Brandon Reese <bjreese(a)gmail.com> wrote: > Kicaj and Matt, > > Thanks for the replies. It is certainly reasonable to ask about the experimental setup, that seems like a good first place to look for oddities. Sorry about using E0 in two different contexts (Athena and Artemis). I'll switch to using E0 for the chosen parameter in Athena's background subtraction and Enot for the guess parameter in Artemis. > > I aligned the scans in Athena using the reference foil absorption edge. I ended up shifting the scans in energy by ~1 eV or less based on the reference foil. I then set the E0 parameter in Athena to the peak of the first derivative. This value varied by about 0.5 eV (or less) between the different samples. This is what I considered when I made the statement about not seeing the oxidation change in the XANES. There is a shift of about 4 eV compared to the reference foil, which I would expect because I am looking at oxides. > > I then extracted the chi(k) into Artemis, and used the same Feff calculations/paths for each sample. In the Artemis fits I am seeing Enot shifts of 1-2 eV, which is a fair bit larger than the error bars. If I chose E0 at peak of the first derivative the Enot came out to be ~7 eV. Since this seemed a little on the big side, I also tried setting E0 to be the top of the white line, in that case Enot came out to be ~1 eV. The Enot shift between samples was about the same either way. Could an argument be made that there is a small shift in the overall oxidation state of the films, possibly contributing to the changes in the conductivity changes in the films? Does anyone have any references about using Enot shifts in this way? > > Scott - The amplitudes of the XANES features are very close. in the normalized spectrum the difference practically 0, and in the derivative the amplitudes are ~5% off. There is bit larger of a difference in amplitude between the samples (in fluorescence) and a pure In2O3 powder (in transmission) of ~10% in the first derivative. The samples are sputtered from oxide sources, so the presence of metallic In should be pretty small. I am interested about your comment on the relative sizes of the first derivative peaks. Comparing my samples to the foil the oxide peak amplitude is bigger than the metal peak by 10% or so. Could this be due to the differences between fluorescence and transmission or not optimizing the experiment to measure the foil? Or could it be due to something else more heinous? > > I noticed on individual fits that the dR for the first shell came out nearly the same (2.162 +/- .007 vs. 2.164) on the two samples, while the Enot's had the 1-2 eV shift between the samples. I tried to fit the two types of samples simultaneously while constraining the dR's (and a few 2nd shell parameters) to be equal to each other and letting the Enot's float. The relative Enot values came out close to what they were before. If I let dR values fit independantly, there was no real change present. In other words the multiple data set fit just made my EB's a bit smaller, but the relative shifts stayed about the same. > > Would there be some reasonable way in a multi-data set fit to constrain the Enot's? > > Brandon > > On Mon, Jun 6, 2011 at 9:04 AM, Matt Newville <newville(a)cars.uchicago.edu> wrote: > HI Brandon, > > If I understand right (and to echo Darius's questions), it seems like > you measure samples with a metal reference, and aligned the spectra in > Athena so that the references matched. That's a fine way to go. I > would ask: how big were the needed energy shifts? > Are the experimental mu(E) spectra aligned well at this point? If > you're studying metal oxides with different oxygen content, you might > very well see oxidation in the XANES. If I understand correctly, > you're saying you don't see this. > > Then, you extracted the chi(k) from the aligned spectra. How much did > E0 vary for the shifted spectra in this background-subtraction step? > > Then, you pulled these chi(k) into Artemis, and see different E0 > shifts in the fits. This E0 is a little different, in that it is the > E0 shift applied to the Feff calculation to match the experimental > spectra. If you use different paths or different calculations, such > E0 shifts might happen, and wouldn't be highly meaningful. > > I know that's not a complete answer, but hopefully that and Darius's > questions will help, > > --Matt > > PS on Q2: 1/ (kR)^2 vs 1 / kR^2 > > This is probably either a typo, or a different convention based on the > definition of f(k) as the electron scattering amplitude. In the Feff > world, it should be 1/kR^2, but using 1/(kR)^2 would just map f(k) to > k*f(k). > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

2 1

Postdoc in XAFS at Australian Synchrotron
by Chris Glover 11 Jun '11

11 Jun '11

Hi All, Im hoping this reaches, or could be passed to, interested candidates in a 2 year Postdoc position at the XAS beamline at the Australian Synchrotron. In short the beamline is based on a 1.9T Wiggler with high flux focused beam of ~ 0.2 x 1 mm. It features 2 experimental hutches, the first is a (fixed) 'standard' RT/He transmission / fluorescence setup, and the second flexible for a range of different setups. The main detector on the beamline is a Canberra 100 element Ge pixel array detector and XIA electronics. Optimizing the experimental performance of this detector be the main focus of the Postdocs project. Further information regarding the beamline and the position are available at: http://www.synchrotron.org.au/index.php/aussyncbeamlines/x-ray-absorption-s… http://www.synchrotron.org.au/index.php/about-us/working-at-the-synchrotron… Relocation and repatriation expenses for international candidates will be provided. I would like to clarify that despite rumors and what may be reported in the local and international media, we are not concerned about the long term security and viability of the Australian Synchrotron continued operations. We are, unfortunately, a hot topic with local politics. For any queries or further information please contact me off the list. Regards Chris Glover.

1 0

Question about shift in E0
by Brandon Reese 08 Jun '11

08 Jun '11

Hi all, I am looking at EXAFS of thin film metal oxides. I am varying both metal content and the oxygen content of the films. I aligned the scans with a metal reference foil collected simultaneously. In Artemis, I have noticed that when changing between films with no extra oxygen versus those with extra oxygen there is a shift in the fitted E0 of ~1.5 eV (after aligning to the foil). I tried setting the E0 in Athena to the peak of the 1st derivative and the peak of the white line with the same result (~7 eV difference). I was a little surprised by the offset because in Athena the E0 values varied by <0.5 eV. I am not sure if the argument could be made that this shift is a result in a changing oxidation state because it doesn't show up in the XANES (at least qualitatively). Are there other experimental effects that could cause a shift like this, or is this likely something real in my material? If anyone want to see a representative group of data, let me know. I also have an unrelated quick (I think) question on the EXAFS equation. In some references I see a term 1/(k R)^2 and in others it is 1/(k R^2). I couldn't really see any reason for the difference, unless it is to correct for subtle differences in how the other terms are defined. Thanks Brandon

5 10

Re: [Ifeffit] Question about shift in E0
by Andrew Korinda 07 Jun '11

07 Jun '11

Sorry Brandon, I see now everything I was asking for was I'm the first few emails. Enot is a local atomic shift in E0 as explained before. (sorry I'm not referencing, I only have my phone available this week) What I understand is you have set E0 to 27944 and 27950 then get Enot of -7 and -1 respectively. This leads to a local edge in the EXAFS equation of 27951 in both cases which is what I was getting at previously. But you say ~ so that means you have an real difference between the two, and the opposite of what I was thinking. Sorry if I caused any confusion. Andy Korinda On Jun 7, 2011 6:27 AM, "Brandon Reese" <bjreese(a)gmail.com> wrote: > I was using feff6. Does your comment mean that when fitting Enot with Feff6, > the results should be considered unreliable? I assumed the 0.5 eV shift in > the mu spectra was small enough that the spectrum could be considered > essentially at the same energy. That is why I was surprised with the > (somewhat) larger shift in Artemis. > > Andy, are you asking what the difference is between E0-Enot for the two > samples? If I picked E0 to be 27944 for all the samples( a round number near > the 1st derv peak), Artemis would fit Enot to be ~5.5 for one group of > samples and ~7 for the other group. Approximately the same offset was > present if I let the parameters get chosen automatically, regardless of the > absolute E0 (within reason). Is this what you were asking, or did I > misunderstand? > > Brandon > > Andy, E0-Enot came out to be 2794 > 2011/6/7 "Dr. Dariusz A. Zając" <kicaj(a)ifj.edu.pl> > >> ** >> Hi Brandon, >> that was a reason why I wanted to clarify which parameters you use. >> E0 (as a Fermi level) in Athena can be taken (but do not must) as a valence >> state of measured ion for K edges, whereas in Artemis delE0 can correspond >> to the potential of the one of nearest atoms to the measured one. If you >> talk about Artemis and calculations, would be also helpful to know the >> version of feff. It is known that for version up to 6. can be problem with >> fitting values of Enot. And of course Matt answered you more clearly... >> The difference of 0.5eV between spectra of reference sample can be simply >> related with the energy resolution of the beam (beamline). >> >> Maybe this will helps you more: >> http://cars9.uchicago.edu/pipermail/ifeffit/2004-June/005607.html >> http://cars9.uchicago.edu/pipermail/ifeffit/2006-February/006811.html >> >> kicaj >> >> W dniu 11-06-07 00:46, Brandon Reese pisze: >> >> Kicaj and Matt, >> >> Thanks for the replies. It is certainly reasonable to ask about the >> experimental setup, that seems like a good first place to look for oddities. >> Sorry about using E0 in two different contexts (Athena and Artemis). I'll >> switch to using E0 for the chosen parameter in Athena's background >> subtraction and Enot for the guess parameter in Artemis. >> >> I aligned the scans in Athena using the reference foil absorption edge. I >> ended up shifting the scans in energy by ~1 eV or less based on the >> reference foil. I then set the E0 parameter in Athena to the peak of the >> first derivative. This value varied by about 0.5 eV (or less) between the >> different samples. This is what I considered when I made the statement about >> not seeing the oxidation change in the XANES. There is a shift of about 4 eV >> compared to the reference foil, which I would expect because I am looking at >> oxides. >> >> I then extracted the chi(k) into Artemis, and used the same Feff >> calculations/paths for each sample. In the Artemis fits I am seeing Enot >> shifts of 1-2 eV, which is a fair bit larger than the error bars. If I chose >> E0 at peak of the first derivative the Enot came out to be ~7 eV. Since this >> seemed a little on the big side, I also tried setting E0 to be the top of >> the white line, in that case Enot came out to be ~1 eV. The Enot shift >> between samples was about the same either way. Could an argument be made >> that there is a small shift in the overall oxidation state of the films, >> possibly contributing to the changes in the conductivity changes in the >> films? Does anyone have any references about using Enot shifts in this way? >> >> Scott - The amplitudes of the XANES features are very close. in the >> normalized spectrum the difference practically 0, and in the derivative the >> amplitudes are ~5% off. There is bit larger of a difference in amplitude >> between the samples (in fluorescence) and a pure In2O3 powder (in >> transmission) of ~10% in the first derivative. The samples are sputtered >> from oxide sources, so the presence of metallic In should be pretty small. I >> am interested about your comment on the relative sizes of the first >> derivative peaks. Comparing my samples to the foil the oxide peak amplitude >> is bigger than the metal peak by 10% or so. Could this be due to the >> differences between fluorescence and transmission or not optimizing the >> experiment to measure the foil? Or could it be due to something else more >> heinous? >> >> I noticed on individual fits that the dR for the first shell came out >> nearly the same (2.162 +/- .007 vs. 2.164) on the two samples, while the >> Enot's had the 1-2 eV shift between the samples. I tried to fit the two >> types of samples simultaneously while constraining the dR's (and a few 2nd >> shell parameters) to be equal to each other and letting the Enot's float. >> The relative Enot values came out close to what they were before. If I let >> dR values fit independantly, there was no real change present. In other >> words the multiple data set fit just made my EB's a bit smaller, but the >> relative shifts stayed about the same. >> >> Would there be some reasonable way in a multi-data set fit to constrain the >> Enot's? >> >> Brandon >> >> On Mon, Jun 6, 2011 at 9:04 AM, Matt Newville <newville(a)cars.uchicago.edu >wrote: >> >>> HI Brandon, >>> >>> If I understand right (and to echo Darius's questions), it seems like >>> you measure samples with a metal reference, and aligned the spectra in >>> Athena so that the references matched. That's a fine way to go. I >>> would ask: how big were the needed energy shifts? >>> Are the experimental mu(E) spectra aligned well at this point? If >>> you're studying metal oxides with different oxygen content, you might >>> very well see oxidation in the XANES. If I understand correctly, >>> you're saying you don't see this. >>> >>> Then, you extracted the chi(k) from the aligned spectra. How much did >>> E0 vary for the shifted spectra in this background-subtraction step? >>> >>> Then, you pulled these chi(k) into Artemis, and see different E0 >>> shifts in the fits. This E0 is a little different, in that it is the >>> E0 shift applied to the Feff calculation to match the experimental >>> spectra. If you use different paths or different calculations, such >>> E0 shifts might happen, and wouldn't be highly meaningful. >>> >>> I know that's not a complete answer, but hopefully that and Darius's >>> questions will help, >>> >>> --Matt >>> >>> PS on Q2: 1/ (kR)^2 vs 1 / kR^2 >>> >>> This is probably either a typo, or a different convention based on the >>> definition of f(k) as the electron scattering amplitude. In the Feff >>> world, it should be 1/kR^2, but using 1/(kR)^2 would just map f(k) to >>> k*f(k). >>> _______________________________________________ >>> Ifeffit mailing list >>> Ifeffit(a)millenia.cars.aps.anl.gov >>> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >>> >> >> >> _______________________________________________ >> Ifeffit mailing listIfeffit@millenia.cars.aps.anl.govhttp:// millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >> >> >> >> _______________________________________________ >> Ifeffit mailing list >> Ifeffit(a)millenia.cars.aps.anl.gov >> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >> >>

2 1

Re: [Ifeffit] Question about shift in E0
by Scott Calvin 06 Jun '11

06 Jun '11

Hi Brandon, I don't find this terribly surprising if your samples are mixtures of a metal and a metal oxide. If you look at the derivative of the XANES spectra of a pure transition metal and its oxides, you'll generally find that the biggest difference is not in the position of the derivative peaks, but in their relative size; for the metal the lower energy derivative peak is much larger than it is for the oxide. A mixture of oxide and metal, therefore, will be primarily evident in XANES through the relative heights of these peaks; sometimes the apparent shift can be very subtle indeed. For example, consider what happens if the first peak in the first derivative is 20 times lower in the oxide than in the metal, and is also 1.5 eV higher in energy. If you have one sample which is 70% metal, and you compare it to a sample which is 40% metal, the tiny contribution of the oxide to the first peak will hardly be visible in either case, and you might see no measurable shift in energy in the XANES for that peak. (You'll see a big change in its amplitude, though.) Likewise, the white line may be dominated by the oxide, and show little shift in the XANES (but once again, a big change in amplitude). An EXAFS fit, however, doesn't suffer from weighting issues in the same way, and may indeed show an E0 shift when the mixture of oxidation states changes. For my description to apply to your system, though, I'd expect you to be seeing substantial changes in the amplitudes of XANES features, even if their position doesn't shift much. Is that the case for your data? --Scott Calvin Sarah Lawrence College On Jun 5, 2011, at 11:56 PM, Brandon Reese wrote: > Hi all, > > I am looking at EXAFS of thin film metal oxides. I am varying both > metal content and the oxygen content of the films. I aligned the > scans with a metal reference foil collected simultaneously. In > Artemis, I have noticed that when changing between films with no > extra oxygen versus those with extra oxygen there is a shift in the > fitted E0 of ~1.5 eV (after aligning to the foil). I tried setting > the E0 in Athena to the peak of the 1st derivative and the peak of > the white line with the same result (~7 eV difference). I was a > little surprised by the offset because in Athena the E0 values > varied by <0.5 eV. I am not sure if the argument could be made that > this shift is a result in a changing oxidation state because it > doesn't show up in the XANES (at least qualitatively). Are there > other experimental effects that could cause a shift like this, or is > this likely something real in my material? If anyone want to see a > representative group of data, let me know. > > >

1 0

Startup Macros
by Emiliano Fonda 31 May '11

31 May '11

Dear all, I would like to write some IFeffit macro and use it in Athena. Actually, I did not find a clean way to load a file with macros at the Athena startup. How can we add our own macros to those that are built-in? Best regards, Emiliano -- Dr. Emiliano Fonda Beamline Scientist (SAMBA) Synchrotron SOLEIL L'Orme des Merisiers Saint Aubin BP48 91192 Gif Sur Yvette CEDEX France Phone +33169359633 Fax +33169359456

2 1

Re: [Ifeffit] more bugs in atoms?
by Gudrun Lisa Bovenkamp 27 May '11

27 May '11

Hi George, I cannot understand how you got this atoms.inp file where the core is stated to be Co1 and there is only Fe. So, I cannot confirm the crystal structure from a database. My problem is solved. I understood that the ATOMS program implemented in Arthemis and ATOMS 2.5 have some bugs that are corrected in ATOMS 3.0 and WebATOMS. When I use those two programs I get a correct crystal structure xyz table in feff.inp. the only reason that I can think of, why your shifting seem to work better is that the atoms.inp file was not representing the correct structure in the first place. This can happen when the situation you wnat to describe is not the situation that was measured by somebody else. Or there is a mistake in the paper. Anyway. Thanks for sharing this idea. Lisa > Date: Thu, 26 May 2011 11:41:08 -0400 >From: George Sterbinsky <GeorgeSterbinsky(a)u.northwestern.edu> > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Subject: Re: [Ifeffit] more bugs in atoms? > Message-ID: <BANLkTi=OH=NCJjmwhkE5vLmnTEao8k3avg(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Lisa, > > Let me just mention one situation I have encountered using atoms, >and how I > resolved it. I am not sure if this is the result of a bug or not, >but > perhaps you can try applying the approach I took to your own >situation and > see if it can resolve your problem. > > The issue I encountered was running atoms for a monoclinic I2/c >structure, > space group 15. > > Here is the atoms input file: > > ! This atoms input file was generated by Artemis 0.8.014 > ! Atoms written by and copyright (c) Bruce Ravel, 1998-2001 > title = ... > space = i 2/c 1 1 > a = 5.51120 b = 5.51120 c = 7.79410 > alpha = 90.0 beta = 90.740 gamma = 90.0 > core = Co1 edge = K rmax = 6.0 > !shift 0.25000 0.25000 0.25000 > atoms > ! elem x y z tag occ. > Fe 0.00000 0.00000 0.00000 Fe1 1.00000 > > If one calculates the Fe-Fe distance between the atom at (0,0,0) and >the > atom at (0, 0, 0.5), from application of the (x, -y, -z+0.5) lattice > translation, one finds a Fe-Fe distance of 3.9705. However, if one >runs the > above atoms input file, this Fe-Fe distance is not found. Instead, a >shift > vector of (0.25, 0.25, 0.25) is needed to get the correct Fe-Fe >distance. > Note, the i2/c space group is listed with only one origin in the > international tables. I determined the necessary shift vector from >trail and > error. It is still unclear to me why it was necessary to include a >shift > vector. So the best suggestion I have is that you can try including > different shift vectors in your own atoms.inp file and see if you >can get > agreement with the crystallography program that way. Since, as I >said, it > isn't clear to me why this fixed my problem, its hard to say if this >is the > same issue you are having, but it may be worth a try. > > It may also be worth while to calculate some atomic distances from >the > lattice positions given in the international tables, and see if >atoms or the > crystallography program is giving you the same thing. > >Finally, let me add on another question for the list here since it is > somewhat related. When one runs the above atoms.inp file with the >(0.25, > 0.25, 0.25) shift vector one finds four Fe1_1 atoms at 3.9701 and >two Fe_2 > atoms at 3.9705. When one then runs Feff, it combines these into a >single >Fe1_1 scattering path with N=6. Is there a command can be placed in >the Feff > input file to tell Feff not to combine identical paths like this? > > Best, > George > >

2 1

Simulation of ion xanes spectra using feff9
by Aurora Clark 27 May '11

27 May '11

Hi; I hope you don¹t mind me posting a question about feff9 to this list, but the feff userlist is defunct. I am trying to learn feff9 by reproducing the work in a JPCA recent paper (JPCA 2011, 115, 2345). I have a calculated structure for U(H2O)8]4+ ion that is nearly identical to that of the paper and so I am using that structure. I have been able to run several test cases for feff9 and I think I have a reasonable understanding of the different cards in feff9 however there are definitely some particulars for these f-element ions that are eluding me. My primary question surround how to deal with ion charge 1. I have tried several options with the ion card, everything from the U having a charge of 4 and the O-atoms zero, to partial charges like 2 and 0.25. However, in each case I get errors that state: ION: Expert option, please read documentation carefully and check your results. ION: Expert option, please read documentation carefully and check your results. U4+-8h2o Now if I run the calculation with no charges on the atoms everything proceeds very smoothly. The manual states that charges typically should not exceed 1 for an atom but in a highly charged system what are you to do? Thank you; Aurora

1 0

Re: [Ifeffit] more bugs in atoms?
by Gudrun Lisa Bovenkamp 26 May '11

26 May '11

Hi George, thanks for responding. I sure imported the same structural information into atoms and the crystal structure program. Lisa > > Hi Lisa, > > I'm not very familiar with PbSO4, so I'm not sure if I can help, but >your > email immediately brought some questions to mind. > >First, did you import the same information into atoms and the crystal > structure program? The way you worded your message made me think >that the > crystal structure program already "knew" the structure of PbSO4, in >which > case perhaps it is using a structure that is slightly different from >the one > you import into atoms. > > Second, what is the source of the structure data you are feeding >into atoms? > In my experience, errors and inconsistencies in the reporting of >structure > data in the literature can lead to unusual results in atoms. > > Best, > George > > >

3 2

Re: [Ifeffit] Can Artemis Simulate a FT Spectrum?
by Palomino, Robert 19 May '11

19 May '11

Matt, Thank you. How would I go about making a theory sum? Would I have to do that in another graphing program or can it be done in Artemis? -----Original Message----- From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of ifeffit-request(a)millenia.cars.aps.anl.gov Sent: Thursday, May 19, 2011 1:00 PM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: Ifeffit Digest, Vol 99, Issue 17 Send Ifeffit mailing list submissions to ifeffit(a)millenia.cars.aps.anl.gov To subscribe or unsubscribe via the World Wide Web, visit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit or, via email, send a message with subject or body 'help' to ifeffit-request(a)millenia.cars.aps.anl.gov You can reach the person managing the list at ifeffit-owner(a)millenia.cars.aps.anl.gov When replying, please edit your Subject line so it is more specific than "Re: Contents of Ifeffit digest..." Today's Topics: 1. Can Artemis Simulate a FT spectrum? (Palomino, Robert) 2. Re: Can Artemis Simulate a FT spectrum? (Matt Newville) ---------------------------------------------------------------------- Message: 1 Date: Thu, 19 May 2011 11:38:45 -0400 From: "Palomino, Robert" <rpalomino(a)bnl.gov> To: <ifeffit(a)millenia.cars.aps.anl.gov> Subject: [Ifeffit] Can Artemis Simulate a FT spectrum? Message-ID: <B32CD18BE9D42745B75847F981879A3602051206(a)exchangemb3.bnl.gov> Content-Type: text/plain; charset="us-ascii" 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

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