Using more than one E0
Hi everybody, I would like to address a couple of questions which are partially related to my recent struggles in fitting some EXAFS data. Im trying to fit my data using several shells of different neighbors including a few single scattering paths and also so multiple scattering contributions (mainly collinear multiple scattering paths) all calculated with the help of FEFF 8.20. Now, I found once in the FEFFIT manual the following suggestion: one might consider using several different E0s for different paths in order to improve the fit. Ok, the explanation was based on some approximations coming from FEFF code which include incomplete core-hole shielding, lack of angular variations of the valence charge distribution and charge transfer between atoms in polar materials. My question is the following: does anyone of you have some experience with such procedure? And if yes, shall than distinguish between the first shell of nearest neighbors and the rest of the atoms in terms of their E0 corrections (using 2 parameters)? Or perhaps one can use separate E0s for each path? Thats one thing The second question concerns the background correction in Artemis: I was trying to find an easy explanation of what this procedure does during the fit but I guess Im still somewhat confused how one can judge whether the spline co-refinement does the right job? Some people on this mailing list underline that one should avoid high correlations between fitting parameters and background parameters in order to make sure that the fit is correct. But is it the only criterion? In some of my fits background line looks kind of constant over the entire R-range which was taken into the fit. Sometimes it becomes like a modulation peaking underneath some scattering paths even if the background parameters dont correlate significantly with fitting parameters I have my doubts whether the result is trustful. Any hints about this procedure? Well, Ill greatly appreciate any comments and feedback from all you guys. I hope Ill be able to share some of my own soon :-) Cheers, Wojciech ********************************************************************* Wojciech Gawelda Laboratoire de Spectroscopie Ultrarapide (LSU) Institut des Sciences et Ingénierie Chimiques (ISIC), Faculté des Sciences de Base (SB-BSP) Ecole Polytechnique Fédérale de Lausanne (EPFL) CH-1015 Lausanne-Dorigny, Switzerland Tel.: +41 (21) 693 0452 Fax.: +41 (21) 693 0422 E-mail: mailto:wojciech.gawelda@epfl.ch wojciech.gawelda@epfl.ch WWW: http://lsu.epfl.ch http://lsu.epfl.ch *********************************************************************
On Thursday 27 May 2004 02:18 pm, Wojciech Gawelda wrote: WG> My question is the following: does anyone of you have some experience WG> with such procedure? And if yes, shall than distinguish between the WG> first shell of nearest neighbors and the rest of the atoms in terms of WG> their E0 corrections (using 2 parameters)? Or perhaps one can use WG> separate E0's for each path? Hi Wojciech, Feff makes approximations when it computes the potentials. The farther away from a muffin tin the real material is, the worse those approximations will be. For a material that is centro-symmetric or not so far away, the potentials should be pretty trustworthy in the extended spectrum. For an assymmetric material, the muffin tin approximation may be suspect. In particular, there is no real concept of a bond in a muffin tin potential. In a real material, there might be phase shifts seen by the photoelectron as it scatters in one direction that are different in another direction. One empirical way of accommodating the shortcomings of a muffin tin potential is to introduce more than one e0 into a fit. But doing so is like approaching the part of an ancient map that says "Here there be dragons." The dragon in this case is the argument that you are just throwing a non-physcial parameter at the problem in order to obtain a fit that is numerically superior. In slangy English, we call these fudge factors. Fudge factors may be bad because they may be highly correlated with the parameters we want to measure. A fudge factor that improves the fit but which cannot be ascribed any physical interpretation should be viewed with suspicion. You should note that the first e0 is NOT a fudge factor. As I mentioned in response to Stefano's mail yesterday, the first e0 is needed to make sure the absolute energy scales of the data and the calculation line up. Thus the first e0 does have a physical interpretation. The bottom line for considering a second e0 is that it must be physically justifiable. If it no more than a fudge factor, it's probably best to stay away. I would insist that all the parameters affecting the various delta_R values all behave sensibly as I change some extrinsic parameter. By this I mean that if I measure, say, a temperature sequence, all the delta_R parameters show a dependence on temperature that is sensible and consistent with anything I might know about the behavior of the material. Temperature is a good way of putting a prior constraint on parameters. There are other ways as well. Similarly sigma^2 values should be sensible, as should any other parameters. I would not expect the best fit values to be hugely different, perhaps not even outside their error bars, when I add the second e0. If adding the second e0 improves the fit quality and tightens other uncertainties without significantly changing best fit values, then I might begin to consider it -- especially if there is some correlation between the paths that need a different e0 and a suspected shortcoming of the muffin tin approximation. Another case where a second e0 might be justifiable is if you expect there to be interstitial electron density in a particular direction (due to strong bonding that the muffin tin approximation knows nothing of) and the use of multiple e0's in particular paths correlates very strongly with what you expect from the real electron density distribution. Again, things that can be justified physically can be considered in the analysis. Actually the argument that parameters should be physically justifiable applies to all parameters, not just your e0 parameters ;-) HTH, B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Bruce, here is another little kick... In order to try to compute a "standard" for background calculation, as suggested, and before running Artemis to try to do that (with the grim results of having the program exiting) I had tried to run feff6 directly on the feff.inp file that I sent out yesterday in order to use the chi.dat file suppositely produced by feff itself. Unfortunately I do not find any chi.dat file produced. I used the following options for the PRINT flag: 1 0 0 0 (the deafult) 1 0 0 1 (the most sentitive choice, for me) 1 1 0 0 (the desperate choice) 1 0 1 0 (same as above...) all not working... Is there a hidden (for me) way to have feff6 produce the chi.dat file? Ciao, Stefano -- ____________________________________________ Stefano Ciurli Professor of Chemistry Department of Agro-Environmental Science and Technology University of Bologna Viale Giuseppe Fanin, 40 I-40127 Bologna Italy Phone: +39-051-209-6204 Fax: +39-051-209-6203 "Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza" Dante Alighieri - Inferno - Canto XXVI
On Friday 28 May 2004 05:45 am, Stefano Ciurli wrote: SC> Bruce, here is another little kick... SC> SC> In order to try to compute a "standard" for background calculation, SC> as suggested, and before running Artemis to try to do that (with the SC> grim results of having the program exiting) I had tried to run feff6 SC> directly on the feff.inp file that I sent out yesterday in order to SC> use the chi.dat file suppositely produced by feff itself. SC> Unfortunately I do not find any chi.dat file produced. I used the SC> following options for the PRINT flag: SC> SC> 1 0 0 0 (the deafult) SC> 1 0 0 1 (the most sentitive choice, for me) SC> 1 1 0 0 (the desperate choice) SC> 1 0 1 0 (same as above...) SC> SC> all not working... SC> SC> Is there a hidden (for me) way to have feff6 produce the chi.dat file? Stefano, It turns out that it is extremely well hidden. Sufficiently well hidden that I had to start digging through the feff6L source code. It seems that the last module (the one that writes chi.dat) is never called in feff6L. Indeed, the call to the last module is commented out in the file feff.f. Question for Matt: Is there a reason that the call to ff2chi is commeted out in feff6L? I just uncommented that block and, in the one case I tried, it ran to completion. If you would like to fix this by hand (you'll need a fortran compiler!), just go to the src/feff6/ folder in the ifeffit source code distribution and edit the file feff.f. Right at the end is a comment out bit that starts "if (mchi .eq. 1)". Uncomment that block, recompile, and move the excutable to its proper place in the path. Then "PRINT 1 0 0 0" will work just fine. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Bruce said:
It turns out that it is extremely well hidden. Sufficiently well hidden that I had to start digging through the feff6L source code.
It seems that the last module (the one that writes chi.dat) is never called in feff6L. Indeed, the call to the last module is commented out in the file feff.f.
Question for Matt: Is there a reason that the call to ff2chi is commeted out in feff6L? I just uncommented that block and, in the one case I tried, it ran to completion.
If you would like to fix this by hand (you'll need a fortran compiler!), just go to the src/feff6/ folder in the ifeffit source code distribution and edit the file feff.f. Right at the end is a comment out bit that starts "if (mchi .eq. 1)". Uncomment that block, recompile, and move the excutable to its proper place in the path. Then "PRINT 1 0 0 0" will work just fine.
Feff6L does not calculate chi.dat because, as far as I can tell, chi.dat has no use. With Ifeffit, the sum over paths is "trivial" (in the physicists sense of "not impossible"). With Artemis, it's actually easy. It's better to do this step with Ifeffit/Artemis because you can use any number of paths you want (as for a spline() standard), add paths from different runs of Feff, put in sigma2 terms, etc, and get the outputs in any format, not the strange format of chi.dat. Did you need it for something? If so, I'd rather link feff6l with libifeffit and use Ifeffit's sum of path to reduce code with repeated functionality. --Matt
On Friday 28 May 2004 12:12 pm, Matt Newville wrote: MN> Feff6L does not calculate chi.dat because, as far as I can MN> tell, chi.dat has no use. With Ifeffit, the sum over paths MN> is "trivial" (in the physicists sense of "not impossible"). MN> With Artemis, it's actually easy. It's better to do this MN> step with Ifeffit/Artemis because you can use any number of MN> paths you want (as for a spline() standard), add paths from MN> different runs of Feff, put in sigma2 terms, etc, and get the MN> outputs in any format, not the strange format of chi.dat. MN> MN> Did you need it for something? If so, I'd rather link feff6l MN> with libifeffit and use Ifeffit's sum of path to reduce code MN> with repeated functionality. That's sensible. My immediate concern was that Stefano had read the feff document and figured that chi.dat would be written because it said so in the doc. It did occur to me to advise him to use Artemis to sum up the paths but I got curious about the thing in feff. I too would also advise people to use Artemis for this purpose, as Matt explains. Now I just need to figure out the solution to the Mac-only bug that Stefano first pointed. Man! That Stefano is a trouble-maker! ;-) B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Bruce,
My immediate concern was that Stefano had read the feff document and figured that chi.dat would be written because it said so in the doc.
you know newcomers.... they try to stick to the recipe as much as possible, and the recipe said that the chi.dat file should be generated. But I agree with the alternative - and more flexible - use of Artemis for that.
It did occur to me to advise him to use Artemis to sum up the paths but I got curious about the thing in feff. I too would also advise people to use Artemis for this purpose, as Matt explains.
thanks
Now I just need to figure out the solution to the Mac-only bug that Stefano first pointed. Man! That Stefano is a trouble-maker! ;-)
well... you are not the first person to tell me that... :-)) Stefano -- ____________________________________________ Stefano Ciurli Professor of Chemistry Department of Agro-Environmental Science and Technology University of Bologna Viale Giuseppe Fanin, 40 I-40127 Bologna Italy Phone: +39-051-209-6204 Fax: +39-051-209-6203 "Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza" Dante Alighieri - Inferno - Canto XXVI
Matt,
Feff6L does not calculate chi.dat because, as far as I can tell, chi.dat has no use. With Ifeffit, the sum over paths is "trivial" (in the physicists sense of "not impossible"). With Artemis, it's actually easy.
yes, that is what I was forced to figure out myself by the absence of any chi.dat file after the feff6 run, but unfortunately the other problem with Artemis popped up...
It's better to do this step with Ifeffit/Artemis because you can use any number of paths you want (as for a spline() standard), add paths from different runs of Feff, put in sigma2 terms, etc, and get the outputs in any format, not the strange format of chi.dat.
I agree fully. I also think that, for the background standard, I could use only the first main path, right?
Did you need it for something? If so, I'd rather link feff6l with libifeffit and use Ifeffit's sum of path to reduce code with repeated functionality.
well... mmm.. not sure I have the tools to follow you on these lines. But will wait for Bruce to produce a fixed tarball (as promised in one of his later messages) for Artemis and generate a .dat spectrum with that. Stefano -- ____________________________________________ Stefano Ciurli Professor of Chemistry Department of Agro-Environmental Science and Technology University of Bologna Viale Giuseppe Fanin, 40 I-40127 Bologna Italy Phone: +39-051-209-6204 Fax: +39-051-209-6203 "Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza" Dante Alighieri - Inferno - Canto XXVI
participants (4)
-
Bruce Ravel -
Matt Newville -
Stefano Ciurli -
Wojciech Gawelda