Re: [Ifeffit] determining reasonable fitting parameters
Thanks to everyone for all the previous responses to my emails, I've learned a lot in the few weeks I've been on this list! I was hoping to build off of the last point Bruce made in message 3 below by asking another question. I am fitting a CeO2 reference from paths generated by feff from a cif file. Since this is my starting point, I made SO2 the same for every path (and used the coordination numbers from the cif file). If I am generating what looks to be a reasonable fit, but my SO2 is in the 0.55-0.7 range, what is my fit trying to tell me? Am I doing something wrong in my initial background subtraction in Athena?
I'm asking about the background subtraction because I recently discovered that there is a CeO2 reference provided in Hephaestus. I exported the data, and tried to fit it in Artemis using a similar methodology I used for my own sample, and I got an even lower SO2. So I don't think the small SO2 value is an artifact of the way the experiment was run (although I might be wrong, I wasn't present when the data was actually collected). The observed difference seems real because the magnitude of the signal in E-space, k-space, and R-space is lower for the Hephaestus sample compared to my experimental sample (see attached image... One note, I'm not sure why the signals are off set in the Energy plot. The Eo's are the same, and if I plot the spectra together in E-space alone, they are not offset. Maybe a bug?).
Neil
-----Original Message-----
From: Ifeffit [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of ifeffit-request@millenia.cars.aps.anl.gov
Sent: Thursday, July 21, 2016 8:01 AM
To: ifeffit@millenia.cars.aps.anl.gov
Subject: Ifeffit Digest, Vol 161, Issue 20
Send Ifeffit mailing list submissions to
ifeffit@millenia.cars.aps.anl.gov
To subscribe or unsubscribe via the World Wide Web, visit
https://urldefense.proofpoint.com/v2/url?u=http-3A__millenia.cars.aps.anl.gov_mailman_listinfo_ifeffit&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=oD5QfHEvBMM5YYrnfMF2YrJNX5aSKvlIRGd2B3iC9kQ&m=TCGdaYbJi7BT0F219p-mQqfSXpTu8VnSiBucuiAZxys&s=KHedxNmDjjawm4epRSuovvOOO9l_MyO4BtDJH2D3i_Q&e=
or, via email, send a message with subject or body 'help' to
ifeffit-request@millenia.cars.aps.anl.gov
You can reach the person managing the list at
ifeffit-owner@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. demeter installation in OSX El Capitan (Ping, Yuan)
2. Re: determining reasonable fitting parameters (Bruce Ravel)
3. Re: determining reasonable fitting parameters (Bruce Ravel)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Jul 2016 05:37:10 +0000
From: "Ping, Yuan"
The reference spectrum provided in Hepheastus only goes out 50eV above the edge. How can you do EXAFS analysis on that? Am I missing something? Here's an EXAFS-length CeO2 ref, pre-edge subtracted and post-edge normalized for your XANES'ing pleasure. mam On 7/27/2016 12:53 PM, Neil M Schweitzer wrote:
Thanks to everyone for all the previous responses to my emails, I've learned a lot in the few weeks I've been on this list! I was hoping to build off of the last point Bruce made in message 3 below by asking another question. I am fitting a CeO2 reference from paths generated by feff from a cif file. Since this is my starting point, I made SO2 the same for every path (and used the coordination numbers from the cif file). If I am generating what looks to be a reasonable fit, but my SO2 is in the 0.55-0.7 range, what is my fit trying to tell me? Am I doing something wrong in my initial background subtraction in Athena?
I'm asking about the background subtraction because I recently discovered that there is a CeO2 reference provided in Hephaestus. I exported the data, and tried to fit it in Artemis using a similar methodology I used for my own sample, and I got an even lower SO2. So I don't think the small SO2 value is an artifact of the way the experiment was run (although I might be wrong, I wasn't present when the data was actually collected). The observed difference seems real because the magnitude of the signal in E-space, k-space, and R-space is lower for the Hephaestus sample compared to my experimental sample (see attached image... One note, I'm not sure why the signals are off set in the Energy plot. The Eo's are the same, and if I plot the spectra together in E-space alone, they are not offset. Maybe a bug?).
Neil
-----Original Message----- From: Ifeffit [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of ifeffit-request@millenia.cars.aps.anl.gov Sent: Thursday, July 21, 2016 8:01 AM To: ifeffit@millenia.cars.aps.anl.gov Subject: Ifeffit Digest, Vol 161, Issue 20
Send Ifeffit mailing list submissions to ifeffit@millenia.cars.aps.anl.gov
To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=http-3A__millenia.cars.aps.anl.gov_mailman_listinfo_ifeffit&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=oD5QfHEvBMM5YYrnfMF2YrJNX5aSKvlIRGd2B3iC9kQ&m=TCGdaYbJi7BT0F219p-mQqfSXpTu8VnSiBucuiAZxys&s=KHedxNmDjjawm4epRSuovvOOO9l_MyO4BtDJH2D3i_Q&e= or, via email, send a message with subject or body 'help' to ifeffit-request@millenia.cars.aps.anl.gov
You can reach the person managing the list at ifeffit-owner@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. demeter installation in OSX El Capitan (Ping, Yuan) 2. Re: determining reasonable fitting parameters (Bruce Ravel) 3. Re: determining reasonable fitting parameters (Bruce Ravel)
----------------------------------------------------------------------
Message: 1 Date: Thu, 21 Jul 2016 05:37:10 +0000 From: "Ping, Yuan"
To: "ifeffit@millenia.cars.aps.anl.gov" Subject: [Ifeffit] demeter installation in OSX El Capitan Message-ID: Content-Type: text/plain; charset="windows-1252" Dear all,
I recently upgraded my mac to OSX El Capitan, and tried to install demeter following the steps at https://urldefense.proofpoint.com/v2/url?u=http-3A__bruceravel.github.io_demeter_&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=oD5QfHEvBMM5YYrnfMF2YrJNX5aSKvlIRGd2B3iC9kQ&m=TCGdaYbJi7BT0F219p-mQqfSXpTu8VnSiBucuiAZxys&s=mJOf0GYWlZWRx9RR_r6Zd26d1gRzqee0VqmVe98TnjY&e=
XQuartz 2.7.9 (xorg-server 1.17.4), Xcode 7.3.1, command line tools, ?sudo port -v self update?, ?port upgrade outdated? were all OK. When I tried ?sudo port install xorg-server demeter?, it showed:
---> Computing dependencies for xorg-server
---> Cleaning xorg-server
---> Computing dependencies for demeter
---> Dependencies to be installed: ifeffit libgcc cctools llvm-3.8 ---> libcxx libffi llvm_select gmp isl ld64 ld64-latest libmpc mpfr ---> pgplot gcc5 ... (a long list)
Then after many attempts to fetch libcxx-3.7.1_0.darwin_15.x86_64.tbz2 from various websites, it showed:
Error: org.macports.archivefetch for port libcxx returned: archivefetch failed for libcxx @3.7.1_0
Error: Failed to install libcxx
Please see the log file for port libcxx for details:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libcxx/libcxx/main.log
The log file is attached. What should I do to fix it? Any suggestion will be appreciated.
Thanks. Yuan
On 07/27/2016 03:53 PM, Neil M Schweitzer wrote:
Thanks to everyone for all the previous responses to my emails, I've learned a lot in the few weeks I've been on this list! I was hoping to build off of the last point Bruce made in message 3 below by asking another question. I am fitting a CeO2 reference from paths generated by feff from a cif file. Since this is my starting point, I made SO2 the same for every path (and used the coordination numbers from the cif file). If I am generating what looks to be a reasonable fit, but my SO2 is in the 0.55-0.7 range, what is my fit trying to tell me? Am I doing something wrong in my initial background subtraction in Athena?
I'm asking about the background subtraction because I recently discovered that there is a CeO2 reference provided in Hephaestus. I exported the data, and tried to fit it in Artemis using a similar methodology I used for my own sample, and I got an even lower SO2. So I don't think the small SO2 value is an artifact of the way the experiment was run (although I might be wrong, I wasn't present when the data was actually collected). The observed difference seems real because the magnitude of the signal in E-space, k-space, and R-space is lower for the Hephaestus sample compared to my experimental sample (see attached image... One note, I'm not sure why the signals are off set in the Energy plot. The Eo's are the same, and if I plot the spectra together in E-space alone, they are not offset. Maybe a bug?).
I don't remember much about the provenance of that CeO2 spectrum. I don't remember how calibration was done (or even if it is reliable). I don't remember much about the sample -- it was a pellet, but I have no way of knowing if it was homogeneous or even if the particles were of the size reported. I guess what I am trying to say is this -- if you trust your CeO2 measurement, you should have more faith in that (or the one Matthew just sent) than in the one from Hephaestus. As for your S02 question, here's some of the standard litany: + the mean free path used by feff was too long. + S02 and sigma^2 are highly correlated. + you did a lousy job normalizing the data (although it sure doesn't look that way from your picture). + your sample had a lot of pinholes. + there is some source of loss in CeO2 that is neglected in Feff (which is, practically speaking, the same as the mean free path comment). You could try fixing S02 and floating an Ei parameter. Or floating both S02 and Ei, although they will be highly correlated. + There is also an energy response to the ionization chambers at such a low energy -- that is, the absorption of the gas in the detector is weaker at the end of the spectrum than at the beginning. In fluorescence, that serves to attenuate the edge0step-normalized spectrum in a way that looks like an enhancement to sigma^2. But it's an attenuation, which could show up in S02. I should mention that in my favorite teaching example -- FeS2 -- by the end of the lecture I have a S02 of something like 0.69. And I just walk away from the lecture at that point :) The reason I do so is that all the rest of the parameters are defensible and I chalk the small S02 up to one of the points above (along with some enthusiastic hand waving -- usually it's time for coffee or lunch by the time I've finished the FeS2 demo!). B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 743, Room 114 Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/
I'm not sure I get your point about ion-chamber response. Shouldn't that normalize out in post-edge spline? If the I0 chamber gets less sensitive as a function of energy, then the post-edge background rises by the same amount as the wiggles get bigger, so it divides out. Similarly for probe-depth effects, depending on concentration. Another couple of possible sources of amplitude error: 1. The model for the pre-edge background is inaccurate, so that its extrapolation to the EXAFS region is incorrect. For instance, if there's a lot of elastic scatter getting into the fluorescence detector, then the pre-edge is curved, and if you model that with a straight line fitted near the edge, them you'll be off far from the edge. Similarly, in a long transmission scan, both pre- and post-edge are curved. My background-sub program has simple models for thse shapes which aren't perfect but help. This effect is really hard to control for because you have no real way to know what the 'right' answer is, most of the time. 2. Overabsorption will definitely reduce the amplitude of the wiggles, and I'm surprise Bruce didn't menntion it. It looks much like pinhole effect. Harmonics do similar things as well in transmission. I still haven't heard how you do EXAFS analysis using the short spectrum from Hepheastus. mam On 7/27/2016 1:23 PM, Bruce Ravel wrote:
On 07/27/2016 03:53 PM, Neil M Schweitzer wrote:
Thanks to everyone for all the previous responses to my emails, I've learned a lot in the few weeks I've been on this list! I was hoping to build off of the last point Bruce made in message 3 below by asking another question. I am fitting a CeO2 reference from paths generated by feff from a cif file. Since this is my starting point, I made SO2 the same for every path (and used the coordination numbers from the cif file). If I am generating what looks to be a reasonable fit, but my SO2 is in the 0.55-0.7 range, what is my fit trying to tell me? Am I doing something wrong in my initial background subtraction in Athena?
I'm asking about the background subtraction because I recently discovered that there is a CeO2 reference provided in Hephaestus. I exported the data, and tried to fit it in Artemis using a similar methodology I used for my own sample, and I got an even lower SO2. So I don't think the small SO2 value is an artifact of the way the experiment was run (although I might be wrong, I wasn't present when the data was actually collected). The observed difference seems real because the magnitude of the signal in E-space, k-space, and R-space is lower for the Hephaestus sample compared to my experimental sample (see attached image... One note, I'm not sure why the signals are off set in the Energy plot. The Eo's are the same, and if I plot the spectra together in E-space alone, they are not offset. Maybe a bug?).
I don't remember much about the provenance of that CeO2 spectrum. I don't remember how calibration was done (or even if it is reliable). I don't remember much about the sample -- it was a pellet, but I have no way of knowing if it was homogeneous or even if the particles were of the size reported.
I guess what I am trying to say is this -- if you trust your CeO2 measurement, you should have more faith in that (or the one Matthew just sent) than in the one from Hephaestus.
As for your S02 question, here's some of the standard litany:
+ the mean free path used by feff was too long.
+ S02 and sigma^2 are highly correlated.
+ you did a lousy job normalizing the data (although it sure doesn't look that way from your picture).
+ your sample had a lot of pinholes.
+ there is some source of loss in CeO2 that is neglected in Feff (which is, practically speaking, the same as the mean free path comment). You could try fixing S02 and floating an Ei parameter. Or floating both S02 and Ei, although they will be highly correlated.
+ There is also an energy response to the ionization chambers at such a low energy -- that is, the absorption of the gas in the detector is weaker at the end of the spectrum than at the beginning. In fluorescence, that serves to attenuate the edge0step-normalized spectrum in a way that looks like an enhancement to sigma^2. But it's an attenuation, which could show up in S02.
I should mention that in my favorite teaching example -- FeS2 -- by the end of the lecture I have a S02 of something like 0.69. And I just walk away from the lecture at that point :) The reason I do so is that all the rest of the parameters are defensible and I chalk the small S02 up to one of the points above (along with some enthusiastic hand waving -- usually it's time for coffee or lunch by the time I've finished the FeS2 demo!).
B
On 07/27/2016 04:39 PM, Matthew Marcus wrote:
I'm not sure I get your point about ion-chamber response. Shouldn't that normalize out in post-edge spline?
Athena edge-step normalizes (i.e. normalizes by a constant) by default. It does not do a functional (or energy dependent) normalization by default in the way you are suggesting.
If the I0 chamber gets less sensitive as a function of energy, then the post-edge background rises by the same amount as the wiggles get bigger, so it divides out. Similarly for probe-depth effects, depending on concentration. Another couple of possible sources of amplitude error: 1. The model for the pre-edge background is inaccurate, so that its extrapolation to the EXAFS region is incorrect. For instance, if there's a lot of elastic scatter getting into the fluorescence detector, then the pre-edge is curved, and if you model that with a straight line fitted near the edge, them you'll be off far from the edge. Similarly, in a long transmission scan, both pre- and post-edge are curved. My background-sub program has simple models for thse shapes which aren't perfect but help. This effect is really hard to control for because you have no real way to know what the 'right' answer is, most of the time.
2. Overabsorption will definitely reduce the amplitude of the wiggles, and I'm surprise Bruce didn't menntion it. It looks much like pinhole effect. Harmonics do similar things as well in transmission.
My brain is really tiny and it's getting to be late in the afternoon here. It's amazing that many bullet points actually made it into the email! B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 743, Room 114 Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/
Oh, so it assumes that chi(k) = (mu(E(k))-spline(k))/const.? Mine does (mu(E(k))-spline(k))/spline(k), which I guess has its own problems - any wiggles driven in the spline will multiply the EXAFS. I haven't seen any effect from this, though. Maybe the right thing is (mu(E(k))-spline(k))/smooth(E(k)) where smooth is a smooth post-edge background such as a polynomial or spline with fewer knots than the subtraction spline or even a tensioned spline. I'd be willing to bet that this refinement will make no detectable difference, especially if you do the reference data the same way. I've found that you can do the most amazingly bogus things and get away with it as long as you do them equally to your reference and unknown, especially if the reference is very similar to the unknown. Of course, you can't rely on that. mam On 7/27/2016 1:45 PM, Bruce Ravel wrote:
On 07/27/2016 04:39 PM, Matthew Marcus wrote:
I'm not sure I get your point about ion-chamber response. Shouldn't that normalize out in post-edge spline?
Athena edge-step normalizes (i.e. normalizes by a constant) by default. It does not do a functional (or energy dependent) normalization by default in the way you are suggesting.
If the I0 chamber gets less sensitive as a function of energy, then the post-edge background rises by the same amount as the wiggles get bigger, so it divides out. Similarly for probe-depth effects, depending on concentration. Another couple of possible sources of amplitude error: 1. The model for the pre-edge background is inaccurate, so that its extrapolation to the EXAFS region is incorrect. For instance, if there's a lot of elastic scatter getting into the fluorescence detector, then the pre-edge is curved, and if you model that with a straight line fitted near the edge, them you'll be off far from the edge. Similarly, in a long transmission scan, both pre- and post-edge are curved. My background-sub program has simple models for thse shapes which aren't perfect but help. This effect is really hard to control for because you have no real way to know what the 'right' answer is, most of the time.
2. Overabsorption will definitely reduce the amplitude of the wiggles, and I'm surprise Bruce didn't menntion it. It looks much like pinhole effect. Harmonics do similar things as well in transmission.
My brain is really tiny and it's getting to be late in the afternoon here. It's amazing that many bullet points actually made it into the email!
B
On 07/27/2016 04:56 PM, Matthew Marcus wrote:
Oh, so it assumes that chi(k) = (mu(E(k))-spline(k))/const.? Mine does (mu(E(k))-spline(k))/spline(k), which I guess has its own problems
Exactly. Both solutions have problems. The potential for trouble with "/const" seems less severe to me and easier to support (in the sense of supporting the use of a software package). So that's why Athena does what she does. B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 743, Room 114 Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/
I think that if the wiggliness in the spline is enough to cause trouble by the mulriplicative effect, then it's probably eating up the wiggles by subtraction, anyway. However, I can see that you wouldn't want the bother and potential for trouble involved in having a second curve for the post-edge division. mam On 7/27/2016 2:08 PM, Bruce Ravel wrote:
On 07/27/2016 04:56 PM, Matthew Marcus wrote:
Oh, so it assumes that chi(k) = (mu(E(k))-spline(k))/const.? Mine does (mu(E(k))-spline(k))/spline(k), which I guess has its own problems
Exactly. Both solutions have problems. The potential for trouble with "/const" seems less severe to me and easier to support (in the sense of supporting the use of a software package). So that's why Athena does what she does.
B
This is also related to whether it is appropriate to apply a McMaster correction to sigma2 after fitting, right? (Or “during,” but since it’s just an offset, it amounts to the same thing.) In Bruce’s method, a McMaster correction is appropriate, although often it’s small in comparison with the reported uncertainties anyway. In Matthew’s method, there is no need for a McMaster correction. Essentially McMaster attempts to correct for using a constant normalization instead of the expected smooth decrease in the normalization factor after the edge. Or am I remembering the meaning of that correction wrong? —Scott Calvin Sarah Lawrence College
On Jul 27, 2016, at 5:26 PM, Matthew Marcus
wrote: I think that if the wiggliness in the spline is enough to cause trouble by the mulriplicative effect, then it's probably eating up the wiggles by subtraction, anyway. However, I can see that you wouldn't want the bother and potential for trouble involved in having a second curve for the post-edge division. mam
On 7/27/2016 2:08 PM, Bruce Ravel wrote:
On 07/27/2016 04:56 PM, Matthew Marcus wrote:
Oh, so it assumes that chi(k) = (mu(E(k))-spline(k))/const.? Mine does (mu(E(k))-spline(k))/spline(k), which I guess has its own problems
Exactly. Both solutions have problems. The potential for trouble with "/const" seems less severe to me and easier to support (in the sense of supporting the use of a software package). So that's why Athena does what she does.
B
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
That's my understanding also.
B
--
Bruce Ravel ------------------------------------ bravel@bnl.gov
National Institute of Standards and Technology
Synchrotron Science Group at NSLS-II
Building 743, Room 114
Upton NY, 11973
Homepage: http://bruceravel.github.io/home/
Software: https://github.com/bruceravel
Demeter: http://bruceravel.github.io/demeter/
On July 27, 2016, at 7:01 PM, Scott Calvin
On Jul 27, 2016, at 5:26 PM, Matthew Marcus
wrote: I think that if the wiggliness in the spline is enough to cause trouble by the mulriplicative effect, then it's probably eating up the wiggles by subtraction, anyway. However, I can see that you wouldn't want the bother and potential for trouble involved in having a second curve for the post-edge division. mam
On 7/27/2016 2:08 PM, Bruce Ravel wrote:
On 07/27/2016 04:56 PM, Matthew Marcus wrote:
Oh, so it assumes that chi(k) = (mu(E(k))-spline(k))/const.? Mine does (mu(E(k))-spline(k))/spline(k), which I guess has its own problems
Exactly. Both solutions have problems. The potential for trouble with "/const" seems less severe to me and easier to support (in the sense of supporting the use of a software package). So that's why Athena does what she does.
B
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
participants (5)
-
Bruce Ravel
-
Matthew Marcus
-
Neil M Schweitzer
-
Ravel, Bruce
-
Scott Calvin