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

Double dipping
by Kelly, Shelly D. 22 Nov '02

22 Nov '02

Hello All, I am new to this mailing list, so I hope my question is relevant. I have several EXAFS data sets that I want to simultaneously fit with one model. One of the data sets was modeled first and the results will be published separately from the rest. I would like to take a bunch of parameters (all of them that do not vary significantly from the known, as determined by individual fits to each data set) from this "known" data set and then fit the series including the "original" to see how a particluar parameter (the number of Ca atoms) changes as the ratio of U to Ca changes. I would like to hear a discussion on the fairness of this approach and how would you calculate the number of independent points? Shelly Kelly

2 1

Athena 0.8.007 and Artemis 0.5.003
by Bruce Ravel 22 Nov '02

22 Nov '02

Hi Folks, I just posted new versions of my two programs on my web site. The source tarball for Unix and OSX users as well as newly built windows executables are in their standard places. Most of the changes this time fix bugs that I discovered last week when I was visiting the wonderful folks at the Alberta Synchrotron Institute. The two most important changes fix the problems displaying the normalized background function and reading chi(k) data that is not on a uniform k-grid. Windows user who are new to Ifeffit: You just need to download the new executable files and drop them on top of the old ones in C:\Program Files\Ifeffit (or wherever you installed Ifeffit on your computer). The big installer file has *not* yet been updated to include these new versions. Unix, linux, or Mac OSX users: The source tarball now includes the ifeffit wrapper that comes with the main ifeffit distribution. Now, when you update ifeffit, it is no longer necessary to cd into the "wrappers/perl/" directory and build the perl wrapper. Instead the wrapper is built at the same time as Athena and Artemis. I am fairly confident that the wrapper gets compiled correctly. It works fine on my linux computer and on Mac OSX. Please let me know if you have any troubles with the compilation so I can fix the build scripts. As always, feel free to post questions, bug reports, or feature suggestions to this mailing list. Special thanks this time to Paul Fons and to all the folks at the ASI. Regards, Bruce -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b 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/

1 0

Re: pgplot question
by Matt Newville 20 Nov '02

20 Nov '02

Hi Paul, On Thu, 21 Nov 2002, Paul Fons wrote: > I noticed (from early on) that although pgplot generated graphics show > all spectra labels on screen, when I save them to a file, that the > lowermost scan of a multiple scan plot always has the label missing. > Is this something that is Mac specific or is everyone suffering from > this problem? I want to try tracking it down a little (perhaps > including sending a note to the pgplot author if helpful). This is my fault -- a bug that's been on the to-do list forever, and never done. I believe this will also cause the same behavior: my.x = range(1,100,1)/10 my.y = sin(my.x) my.z = cos(my.x) newplot my.x, my.y, key='sin' plot my.x, my.z, key='cos' #everything is fine... plot xmax = 8 and the most recent 'key' gets lost. Making a hardcopy simply does a plot() with a different device, and so often tickles this error. Workarounds include adding the last trace twice, as in newplot my.x, my.y, key='sin' plot my.x, my.z, key='cos' #everything is fine... plot my.x, my.z, key='cos', color='red' which will then trick a second plot(). Anyway, it's all my fault, not PGPLOT's. Probably should fix it huh?? --Matt

1 0

Ifeffit 1.0075
by Matt Newville 13 Nov '02

13 Nov '02

Hi Everyone, Ifeffit 1.0075 is now available. There are some bug fixes related to erasing paths, which caused serious problems with artemis. There was also a change in the guts of how the Perl wrapper was built, as the older one failed to compile with gcc3.2 on RedHat 8.0. I have not tried this on Mac OS X, and don't foresee any problems, but if someone is brave enough to try it, please let me know if it fails. The most significant change in 1.0075 is the inclusion of Feff6 in the source tree and a Windows executable of Feff6 in the Windows installer. That right, there is now a free version of Feff6 included with Ifeffit!! The plan is to turn this version of Feff into a library that can be called directly from the perl and python scripts. That is, the 'run feff' button on TkAtoms might actually work someday!! If you're as thrilled about this as I am, don't hesitate to thank John Rehr repeatedly. There are new versions of sixpack, artemis, and athena in the Windows installer. The latest source code for these should be downloaded from Sam's and Bruce's web pages. Special Thanks to John, Sam, and of course Bruce, --Matt

4 6

ifeffit and feff
by Bruce Ravel 06 Nov '02

06 Nov '02

Ahmed, I trust you do not mind that I answer your question on the ifeffit mailing list. It seems of sufficiently broad interest that an answer in that forum is appropriate. You asked: AS> I received a note with the latest version of your software. In my AS> understanding that the latest version includes the Feff6L without AS> a license fee. Does this mean that by downloading the latest AS> version of ifeffit, so that I do not need to buy a license of AS> feff? Well, my answer is ether a qualified yes or a qualified no, depending on what your interests are ;-) *IF* you are interested only in the extended EXAFS features of Feff and *IF* you do not think that you need any of the more recent developments of Feff (most notably, self consistent potentials), then you probably do not need a license for Feff. Feff6L is free in both senses of the word -- it doesn't cost you any money and you may freely use, modify, and redistribute the code under the terms of its license. See this post from John Rehr to the mailing list about the Feff6L license: http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2002-November/000169.html However, if you are interested in computing XANES, partial electronic densities of state, charge transfer or ab initio Fermi energies, you will need to license a copy of the latest version of Feff. If you are interested in the latest developments of such theoretical topics as self-consistent potentials, improved self-energies, S02 calculations, resonant scattering corrections, or a whole host of other features available in the latest Feff and not available in Feff6L, you will need to license a copy of the latest version of Feff. Feff6L is useful code for the extended exafs practitioner. If that were not true than Matt would not have been so effusive in his post yesterday announcing Ifeffit 1.0075. While Feff6L is useful and usable for exafs analysis, you must be aware that it is largely limitted to exafs analysis. If you need XANES calculations, you need a Feff8 license. All clear? B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b 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/

1 0

FEFF6L - Lite EXAFS only version of FEFF6 source code
by John J. Rehr 05 Nov '02

05 Nov '02

Dear Feff developers, In an effort to facilitate the development of EXAFS analysis software, the FEFF Project has made available the source code for a "lite" subset of the FEFF6 distribution sufficient for EXAFS analysis, named FEFF6L. Thus cross-sections and XANES capabilities of FEFF6 are disabled in FEFF6L. A copy of the FEFF6L distribution can be found (shortly) on the FEFF Developer download pages. The subroutines are distributed with a License that permits redistribution without a license fee; see the LICENSE in the distribution for details. c/////////////////////////////////////////////////////////////////////// c Distribution: FEFF6L c Copyright (c) [2002] University of Washington c c This software was prepared in part with US Government Funding under c DOE contract DE-FG03-97ER45623. c c Redistribution and use of this Distribution in source and binary c formats, with or without modification is permitted, provided the c following conditions are met: c c Redistributions must retain the above notices and the following list c of conditions and disclaimer; c c Modified versions carry the marking c "Based on or developed using Distribution: FEFF6L c Copyright (c) [2002] University of Washington" etc. The distribution FEFF6L should not be confused with the full distribution of FEFF6. Also the FEFF Project will continue to develop advanced versions of the FEFF codes which will be distributed with the UWOTT License and license fee. Comments on this EXAFS version are welcome. Sincerely, FEFF Project PIs J. J. Rehr A. L. Ankudinov

1 0

Re: [Ifeffit] Debye factor and S02 correlation
by Bruce Ravel 05 Nov '02

05 Nov '02

jjr> I don't understand Bruce's remark. Incorporating prior knowledge jjr> into statistics is completely proper according to modern jjr> statistical theory. If two quantities are correlated and one jjr> knows one, then naturally the other is better determined. Well, leaving aside the question of whether one can call a Levenberg- Marquardt fit "modern", I agree that one can set a value and call it part of the model. One does that all the time in any fitting problem. But in that case you are asserting a value with no error bar. There is no situation where you can assert a value AND an error bar. My concern was your statement that you somehow knew the value of the error bar on S02. If it floats, you have to use the error bar the fitting algorithm reports. But the most important thing in my comment and the most important thing in the discussion on the topic of amplitude terms in exafs that we have seen in the last week on this list is that, in a difficult fitting problem (i.e. not copper), one rarely has reliable a priori knowledge of the *product* of S02, coordination, and the systematic uncertainties. Thus one rarely has a reliable prior in the Baysian sense. B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b 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/

1 0

rebinning data
by Carlo U. Segre 05 Nov '02

05 Nov '02

hello All: This is to bring back up a subject that was discussed a few months ago on the list. We have been diligently working on a python algorithm for rebinning XAFS data from high point density slew scans. I have been testing it and I hope that there will be a complete version available shortly. It is in the form of a unix filter which takes a few parameters (edge energy, energy above the edge where rebinning is to begin, step size in k for rebinning) and spits out a modified file for each input file. There are just a couple of small glitches in how it handles data points with the same energy (this causes athena to pop up an annoying dialog) but that should be solved this week. I am more than happy to send it to anyone who would like it. Matt, I remember that you had suggested that we send code. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre

3 3

Re: [Ifeffit] Debye factor and S02 correlation
by John J. Rehr 05 Nov '02

05 Nov '02

Matt's test of fitting the inelastic losses using So2 and an effective mean free path (via a constant imaginary shift Ei in the net lifetime width in FEFFIT) is quite interesting. In particular the results are consistent with our current understanding of the physics, namely that the inelastic losses are generally overestimated by the plasmon-pole self energy. Thus one expects Ei to be negative to compensate for errors in this self-energy model. Also it's particularly encouraging that one can fit *both Ei and So2*. I'm not too worried by the evident correlation between these parameters since they both smoothly affect the overall amplitude; what matters is the value of Ei when So2 is about 0.9. Matt wrote: >This seems like a fine approach to me, and it could be automated, >at least somewhat. Feffit/Ifeffit have Ei as a path parameter, >so setting So2 to 0.9 and floating Ei is possible right now. >Using Ei instead of So2 has a couple possible benefits: > 1. Not completed correlated with N (though see below!) > 2. Can accomodate measurement resolution issues. > 3. Might be a little easier conceptually on the new people. > >For one variation on the canonical 'Cu 10K first shell fit', >with sigma2 varying as well, I get these values: > So2 Ei chi_square r-factor > 0.93(0.03) 0.00(fix) 119. 0.0017 > 1.00(fix) 0.55(0.25) 128. 0.0018 > 0.95(fix) 0.14(0.24) 120. 0.0017 > 0.90(fix) -.29(0.23) 116. 0.0016 > 0.85(fix) -.75(0.23) 116. 0.0016 > > 0.87(0.14) -.58(1.27) 116. 0.0016 > >The last one had both So2 and ei (and sigma2!!) floating. The >correlation between them was 0.98, higher than that between So2 >and sigma2, which was a mere(!) 0.94. So it looks like, for this >data, So2 really does want to be ~0.90 +/ 0.05, and Ei wants to >be 0.00 +/- 0.25. As I read the numbers for the minimum chi_square, I would say that the results suggest Ei = -.52 +/- .3 I don't believe the error bar on So2 of +/- .14. Probably +/- .05 is more like it, so the error bar on Ei will be much smaller than 1.27. Also, I think if you look at plots of the fits, they look better with a slightly negative Ei. We would very much like to see more evidence for the inadequacy of the plasmon pole self energy. Thus I would encourage more fits to include E_i as a fitting parameter, with So2 kept under control (e.g. fixed or floating in a range 0.9 +/- .05, assuming edje jump is well defined). J. Rehr

2 1

Re: [Ifeffit] Debye factor and S02 correlation
by John J. Rehr 04 Nov '02

04 Nov '02

Hi Everyone, I agree with Matt's assessment: > ... my view is that the >errors in the calculated mean-free path may have a much stronger >energy dependence than the errors in the calculated So2. From >the analysis point-of-view, I prefer to think of So2 as >k-independent, and put all k-dependent pieces go into lambda(k) >or F(k). Feff tries to include all loss terms as well as it can. There are two ingredients in the mean free path lambda(k) lambda_k approx k/[Im Sigma(E) + Gamma] 1) The core hole lifetime Gamma - FEFF estimates this by interpolating from tabulated values. This rough estimate should not lead to serious errors, in my view, since a 10% error in the lifetime translates to only few percent error at worst in the loss factor exp(-2 lambda R). 2) The self energy Sigma - FEFF uses an electron gas plasmon pole approximation. which can easily be off by 1-2 eV. This is the most serious error and leads to large energy dependent errors in lambda_k. >So2 _is_ calculated (if crudely in Feff6 and 7 -- I don't know if FEFF6-8 will make an atomic value of So2 if one sets S02 = 0 in the HOLE card. This approximation is unsatisfactory since it can't account well for the valence electron contributions or interference effects which dominate So2. I don't think it can be trusted - at least to better than 10%. >Luke Campbell's work on improved So2 is included in Feff8 yet). >So one might even expect that So2 should be 1, and even find it a Luke Campbell's routines are not in FEFF8 yet as they are not yet fully automated or ready to be integrated. This will us take some months. Moreover, Luke still uses a plasmon-pole self energy, which we want to improve. >little strange that it's usually around 0.9. Clearly, there are >loss terms that are not taken into account well enough in Feff. >My view is that it's not well known whether this is dominated by >an k-dependent term (ie, should be put into F or lambda) or a >k-independent term (So2). The remarkable bit of physics here is that interference terms between extrinsic and intrinsic losses and hence tend to suppress shake-up/shake-off effects. In any case, my suggestion in fits would be to treat the loss terms using a constant and an effective mean free path: a) set So2 = constant approx 0.9 b) fit the mean free path, e.g., by fitting the core-hole effective lifetime. I'd be interested in feedback on this suggestion. Can it be automated within FEFFIT? Cheers, John Rehr

2 1