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

re:fits
by k-kupiecki＠northwestern.edu 15 Jan '05

15 Jan '05

Thank you Bruce and Shelley! I just wanted to thank Matt, Bruce and everyone involved with IFEFFIT/Artemis/Athena... it has been a Godsend.... I couldn't have stumbled on it at a better time (I'm frantically trying to analyze about 4 beamtimes worth of SEXAFS data for papers and my thesis and WINXAS wasn't really working out for me)!!!!! Does anyone have any suggestions for additional literature in regards to better understanding the quality of fits and the parameters involved?.... or perhaps know when we might be able to expect a updated version of the Artemis literature? (What is currently there has helped me sooo much that I've been checking for an update every couple of weeks hoping to get see sections 2.2-3.2..... ) Also.... I guess I've realized that only knowing IFEFFIT with Artemis I kinda take things for granted (like I didn't know that IFEFFIT was having problems, in certain cases since I had only been checking the "Results" and the error messages on the bottom of the window....) which meant I missed errors like this in the IFEFFIT (since I didn't notice anything unusual in the "Results"): ............ # Do the fit! ## fitting difference of Cov_0_06ML_bl1435_111703.chi and one or more paths ... ## === data set #1 of 1 feffit(1-8, group=data0_fit, chi=data0.chi, k=data0.k, kweight=2.00, rmin=1, rmax=4, kmin=2.5, kmax=15, dk=2, kwindow=kaiser-bessel, fit_space=R, do_bkg=no, data_set=1, data_total=1) feffit fitting 1 data sets fitting ... fitting ... fitting ... fitting ... fitting ... fitting ... fitting ... fitting ... no uncertainties estimated! fit gave a warning message: too many fit iterations. try again with better guesses or a simpler problem. ............................................... I guess my question is.... is there anything else I should be looking for in the IFEFFIT printout that I might not otherwise notice by just using Artemis and looking at the error messages and "Results"? Thanks for the input! Sincerely, Kristine Witkowski Northwestern University

6 8

RE: [Ifeffit] Using more than one E0
by Kelly, Shelly D. 14 Dec '04

14 Dec '04

Hi Guys, I wanted to add another comment about using multiple E0's. One of the best formulas that I have found involves assigning different atom types different E0's. This method seems to work well for M.S. paths. Here is an example of how it goes. I think that Daniel Haskel was the first to publish this type of E0 stuff. "Single and multiple scattering XAFS in BaZrO3: a comparison between theory and experiment" D. Haskel, B. Ravel, M. Newville and E. A. Stern Physica B 208&209 (1995) 151 Lets pretend that we have a copper oxide that we want to model. First shell Oxygen called O1, Second shell Cu called Cu1, Third shell Oxygen called O2. This method would use three E0's. One for the first shell oxygen atoms, Eo1. One for all the Cu atoms Ecu. and one for all other oxygen atoms Eo2. The Cu-O1 path has E0=Eo1. The Cu-Cu1 path has E0=Ecu. The Cu-O2 path has E0=Eo2. The Cu-O1-Cu-O1 path has E0=Eo1, (only scattering from O1 atom). The Cu-O1-Cu1-Cu path has E0=0.5*Eo1+0.5*Ecu. (scattering once from O1 and once from Cu1) ... And so forth and so on. Now if you set something like this up. You need to look at the results carefully and see if it works. Generally, scattering from an atom that has lost an electron due to an ionic bond will have a positive deltaE, and scattering from an atom that has gained an electron will have a negative deltaE. Of course this negative/positive deltaE is added to the alignment deltaE. If the values for Eo2 and Ecu are the same within the uncertainties of the measurement then you need to make them the same variable, so then you will only have two energy shifts, but you can still use it. This is most often the case as Matt mentioned but I always like to test it out. In addition, one electron transfer is about a shift by 6 eV, so if these values differ by more than say 10 eV something is not right. Since the shift is generally smallish, say 2 eV, your fit has to be really accurate to "see" these shifts. In particular they seem to be most important when you have all the deltaR values constrained in some way so that the error in deltaR is really really small. For example all deltaR values are related to unit cell parameters and atomic positions or and overall expansion term. HTH Shelly -----Original Message----- From: Wojciech Gawelda [mailto:wojciech.gawelda@epfl.ch] Sent: Thursday, May 27, 2004 1:18 PM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: [Ifeffit] 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. I'm 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 E0's 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 E0's for each path? That's 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 I'm 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 don't correlate significantly with fitting parameters I have my doubts whether the result is trustful. Any hints about this procedure? Well, I'll greatly appreciate any comments and feedback from all you guys. I hope I'll 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(a)epfl.ch WWW: <http://lsu.epfl.ch> http://lsu.epfl.ch *********************************************************************

2 1

ifeffit and Mac OSX
by Matt Newville 03 Jul '04

03 Jul '04

Hi Raja, On Mon, 7 Oct 2002, rajasekaran swaminathan wrote: > Hi Matt, > > I tried again over the past few days to install the binary > installer on my mac (OS X.2). I couldn't find an attached aquaterm > / pgplot demo. The Aquaterm program opens, but I cannot see any > windows come out from that application. I mean, it is just like a > blank application. When I type ifeffit on Terminal app, it doesnt > recognise the presence of ifeffit in the ifeffitosx directory. i.e. > it says that the command is not found. The executable works > perfectly well on a Windows machine, and I was wondering whether > there are any such equivalents for a Macintosh machine. I also dont > think that the installer comes with athena/artemis/tkatoms etc.. Do > you have any other recommendations to resolve this issue? Also,if > it is possible, can I get a CD of these programs for a Macintosh > equivalent to an executable version for the Windows? > > I appreciate your help in this regard. I have used the binary installer once on a OS 10.1 system. It worked for me (after following the simple included instructions, of course) and plotting with Aquaterm did work. I haven't tried 10.2. I know the Mac binary installer does not include athena, artemis, or tkatoms. I believe it only provides the command-line ifeffit. I'm not sure I can answer many other questions about it. I don't know enough about it or 10.2 v. 10.1 issues to know how well it would work with 10.2. If the aquaterm/pgplot demos don't work, I'd guess it's a more serious problem and that the binary installer may not work. Is the Fink / X-Windows / PGPLOT installation procedure too big of a hassle? I know that can work, and that athena will work too. I also believe that the instructions are simpler for 10.2 than 10.1 (especially with respect to getting perl/Tk to work), but haven't tried this myself. I'm copying this message to the ifeffit mailing list, hoping that someone else may have better answers to these questions. How necessary is a complete binary installer for Mac OSX? Thanks, --Matt

4 4

Re: [Ifeffit] Using more than one E0
by Scott Calvin 07 Jun '04

07 Jun '04

Hi Wojciech, I have another suggestion. It is my secret, completely untested belief (which I am now revealing to everyone on this mailing list!), that some of the cases of "successful" fits using multiple E0's are masking problems caused by not considering a third cumulant. For those who may not know the role of this parameter, it in essence measures asymmetry in the distribution associated with a path. For example, if a pair of atoms are more likely to separated by a distance considerably larger than the mean separation than by a distance considerably smaller than the mean separation, then the third cumulant is positive. (The mathematical definition is that the third cumulant is the mean cube of the difference from the mean, in the same sense that sigma2 is the mean square of the difference from the mean.) In most cases, the third cumulant is small. Nevertheless, if it were 0 in all cases, then materials would not show any expansion with temperature! Through symmetry arguments, it is pretty clear that the third cumulant is most likely to be significantly nonzero for nearest-neighbor paths. What does this have to do with fitting different E0's? E0 and the third cumulant both affect the phase of the EXAFS signal, although they are weighted in different ways by k. Nevertheless, if a nonzero nearest-neighbor third cumulant is called for, allowing a different E0 for the nearest-neighbor instead would probably also improve the fit statistically. In this case, however, while the use of a third cumulant can be justified on physical grounds relatively easily, the use of a separate E0 is an arbitrary non-physical attempt to improve the statistics. So as far as I am concerned, I am more inclined, if my fit is not quite working out, to try allowing the third cumulant for paths in the first coordination shell to vary than I am to introduce multiple E0's. In fact, I usually do this at some point during the fitting process even if my fit is behaving fairly well to reassure myself that the third cumulant is 0 to within the uncertainty of the fit, and that constraining it to 0 is not distorting the values of the parameters I am interested it. Take all of this with a grain of salt; I wrote my dissertation on the third cumulant, and, to paraphrase Bruce, since I've spent a lot of time making a nice hammer, everything tends to look like a nail... --Scott Calvin Sarah Lawrence College > >I would like to address a couple of questions which are partially >related to my recent struggles in fitting some EXAFS data. I'm >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 E0's 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 E0's for each path?

3 6

trap file
by Stefano Ciurli 01 Jun '04

01 Jun '04

Hi Bruce, I installed the new horae (035) and played around with the ZnO tutorial using the new version of Artemis. I called the program in the directory where the ZnO dat file reside from the command line. The project apj1 (run with all the indications in the journal) worked smoothly. As soon as I try to read in the apj2, the following trap message pops up: # Artemis 0.7.005 # This file created at 00:19:09 on 31 May, 2004 # using darwin, perl 5.008001, Tk 804.027, and Ifeffit 1.2.5 # Workspace: /Users/stefano/.horae/stash/artemis.project.3/ The following message was trapped by Artemis on a SIGWARN: Artemis0.7.005warn/Users/stefano/.horae/stash/ARTEMIS.TRAPCODE(0x1e3dff8)/Users/stefano/.horae/stash/artemis.project.3/ at /Applications/Ifeffit/bin/artemis line 1562 main::__ANON__('Tk::Error: could not open /Users/stefano/.horae/stash/artemis...') called at blib/lib/Tk.pm (autosplit into blib/lib/auto/Tk/Error.al) line 488 Tk::Error('MainWindow=HASH(0x8f44c)','could not open /Users/stefano/.horae/stash/artemis.project.3/...','main::nnnn_header at /Applications/Ifeffit/bin/artemis line 4386','main::read_path at /Applications/Ifeffit/bin/artemis line 10872','main::open_project at /Applications/Ifeffit/bin/artemis line ...','main::read_data at /Applications/Ifeffit/bin/artemis line 6901','main::dispatch_read_data at /Applications/Ifeffit/bin/artemis...','main::__ANON__ at /Applications/Ifeffit/bin/artemis line 586','Tk callback for ..frame.menubutton.menu.project_data',...) called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 eval {...} called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 Tk::MainLoop() called at /Applications/Ifeffit/bin/artemis line 1707 End of trap file. Exactly the SAME error message pops out when I try to save a fit as chi(k). Obviously I am stuck... Any help here? Again, there must be some problem with the perl libraries... HELP!!! 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 -- ____________________________________________ 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

3 7

source tarball for horae-035
by Bruce Ravel 01 Jun '04

01 Jun '04

Hi folks, I just released the source code tarball for the latest version of my software. Those of you who use the source can run the horae_update script now. Or, you can grab the new version of the horae_update script from here and try it: http://leonardo.phys.washington.edu/~ravel/software/exafs/utilities/horae_u… The new version allows connection to a local proxy and grabs the tarball from SourceForge. Type "horae_update -h" for help on using the new features. This new version of horae_update is included in the tarball. This release is purely a bug fix release, mostly for Artemis. It addresses all the outstanding issues brought to my attention over the last week, including the problems related to the Mac OSX package. A windows executable will be made next week. Thanks to all the folks who provided bug reports for this release, including Shelly Kelly, Stefano Ciurli, Gleb Pokrovsky, and Peter Southon. B -- Bruce Ravel ----------------------------------- ravel(a)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/

4 7

Athena normalization and deglitching bugs
by Scott Calvin 01 Jun '04

01 Jun '04

Hi Bruce, I figured I'd post this to the Ifeffit list so that others could be alerted to similar problems, but I'll send you an Athena project file exhibiting this problem separately, so that everyone's in-boxes don't get cluttered with attachments. I'm using Athena 0.8.028 on Windows XP. First of all, on any file, including the copper data that comes with Athena, there is a bug. To see it, go to the deglitch screen, and change Emax by picking a point off the plot. Then replot. From now on, the green "tolerance" lines extend from Emax up to the end of the plot, rather than from Emin to Emax. This seems to affect only the screen display (i.e. it still deglitches the intended range), but it does make it harder to see what will get deglitched. The second behavior is best revealed with the project I am sending you separately. I am not positive it is a bug, but it doesn't match what I would expect. In the project I am giving you, the data is very glitchy (lots of Bragg peaks). Go down to the group labeled SBT/B Bi LIII Merge and plot in E-space with the post-edge line. Does it look right to you? It looks like the normalization line is considerably higher than it should be given the normalization range chosen, with only a few glitches above it. Is that something I don't understand about the way the post-edge line is chosen, or is it displaying the line wrong, or is it calculating it wrong? Thanks--the new features in Artemis are great, by the way. --Scott Calvin Sarah Lawrence College

2 1

Updating problems.
by Dave Baker 28 May '04

28 May '04

Hello all. This message is directed mainly toward Bruce, but if anyone else has any suggestions, please feel free to contribute. For a while now, I have been using Athena and Artemis on my work computer with a broadband internet connection, and all the updates have auto-detected and installed without a hitch. The problem is that now, I want to use the programs on my home computer, for which I am simply too cheap to buy anything better than dialup service. The updater, unfortunately, has choked several times when trying to download and install the 9 updates it says I need. (In fact, one time the echo screen stated that all the updates were installed, but when I restarted and opened Athena and Artemis, I was confronted with the old versions of the programs.) I haven't seen any "new and fully updated windows installers" on either Matt's or Bruce's pages, and it isn't clear to me how to get at the update files without the assistance of the updater itself. (I seem to recall reading that one can simply unzip the ifup_00x.zip file in the Ifeffit directory, run make_bats.exe, and all will be well.) Is there a way I can use the broadband connection at school to grab the updates and install them myself on the home computer without the use of the updater? Or, is there a place that the updater stores the .zip files after it's done updating the program, so I can just grab them off the work computer? Thanks for your help! -Dave ------------------------------------------------------------------------ -- North Carolina State University Dept. of Physics 2700 Stinton Dr. Box 8202 Raleigh, NC 27695 Ph: 919-515-5017 Fax:919-515-7331 email: dabaker(a)unity.ncsu.edu ------------------------------------------------------------------------ --

2 1

an update on the Mac OSX problem
by Bruce Ravel 28 May '04

28 May '04

Hi, I just wanted to let the mac users know that I have finally flushed out the problem that Stefano and Matt reported. There is most certainly a crippling problem with 0.7.004 on the Mac. In fact, the problm does not have to do with the Mac per se, but with the version of perl/Tk used to build the codes in the Mac installer. As some of you may be aware, the perl/Tk world is in the middle of a transition between two major versions of the toolkit. One of the challanges for me has been to write code that works seamlessly despite certain internal differences. It turns out that I finally traced the problem to a rather obscure difference between the older and new perl/Tk code bases. Fortunately there is an easy solution (although it will take me a while to find all the places where I need to apply it) and I think that I'll be able to post a new source code tar ball by the end of the day. Also fortunately, Windows users will not see this problem using the current builds of the windows executables. Note that the Mac installer currently has 0.7.003, so those who have installed the installer but not updated to 0.7.004 are unaffected. Finally, linux and other unix users who are using a perl/Tk 800 release will be unaffected. The bug is specific to perl/Tk 804. The amusing thing is that Stefano originally reported this as a problem loading an atoms.inp file. That turned out to be quite a red herring. The problem has nothing to do with the part of the code that handles atoms or feff files! Regards, B -- Bruce Ravel ----------------------------------- ravel(a)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/

2 1

Using more than one E0
by Wojciech Gawelda 28 May '04

28 May '04

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 confusedhow 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 pathseven 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(a)epfl.ch WWW: <http://lsu.epfl.ch> http://lsu.epfl.ch *********************************************************************

4 7