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

trouble with Tk on Mac OSX
by Michel Jaouen 03 Jun '04

03 Jun '04

Hi folks, I think somethings is broken with Tk. As reported in my previous e-mail I found a problem (I have not before 1st june!) with the space group browser of Atoms. In fact I have the same error with Artemis when pressing the fit button! The following message was trapped by Artemis: Artemiswarn/Users/mjaouen/.horae/stash/ARTEMIS.TRAPCODE(0x1e18a84) at /Applications/Ifeffit/bin/artemis line 1491 main::__ANON__('Tk::Error: unknown option "background" at /Library/Perl/ 5.8.1...') called at blib/lib/Tk.pm (autosplit into blib/lib/auto/Tk/Error.al) l ine 488 Tk::Error('MainWindow=HASH(0x61e5d8)','unknown option "background" at /Library/Perl/5.8.1/darwin-thr...','Tk callback for .sgb.frame','Tk callback for . sgb.frame.ysbslice','Tk callback for .sgb.frame.ysbslice.corner','Tk callback for ..sgb','Tk callback for .sgb.button1','Tk callback for .frame.menubutton5.menu', 'Tk::__ANON__ at /Library/Perl/5.8.1/darwin-thread-multi-2leve...',...) 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 1627 What makes me crazy is that all was running smoothly before tuesday :-) Cheers Michel -- __________________________________________ Michel Jaouen Universite de Poitiers - UFR Sciences - SP2MI LMP UMR 6630-CNRS Boulevard Pierre et Marie Curie - Teleport 2 BP 30179 86962 Futuroscope - Chasseneuil Cedex France Tel : (33) 5 49 49 67 37 Fax : (33) 5 49 49 66 92 e-mail : Michel.Jaouen(a)univ-poitiers.fr __________________________________________

2 1

news
by Bruce Ravel 02 Jun '04

02 Jun '04

Hi everybody, Today I made another new release of the source code tarball and built a new Artemis executable for windows. Users of each of the three major platforms should read the notes below for information about this release. This will be the last release for a while. June and July will be very busy for me and I will have scant time to work on the codes until August at the earliest. I will be reading bug reports and suggestions and will address them when I get back to work on the codes -- so please continue to send them in. Hopefully whatever bugs are lurking in there will not prove too difficult to work around. This release attempts to fix a problem managing the project folder in Artemis, as reported by Stefano Ciurli. The new version works correctly for me, your milage may vary. If any of you will be at the ISSRNS conference in Zakopane Poland next week, please introduce yourself! I hope everyone has a great summer! (Or a great winter for those of you in the southern hemisphere!) B -------------------- O -------------------- Notes for each of the platforms follow: Linux (and other non-Mac OSX unixes): The source code tarball is on SourceForge and on my web site. If the horae_update script fails, try using the --mirror argument as described in the help text (horae_update -h). Mac OSX: There was no time to make a new installer package. For the time being, you can use the most recent installer package, then update to the latest source code tarball from the command line. This requires downloading the source tarball from SourceForge and unpacking it. Then, from the command line, type "perl Makefile.PL" then "make" then "sudo make install". The last step will prompt for the administrator password. If you run into trouble, ask on the mailing list and one of the Mac users should be able to help you. Windows: There was no time to prepare a new updater package for windows. Virtually all of the changes in my codes since the last updater package have been bug fixes to Artemis. So I have made a new Artemis executable and placed it here: http://leonardo.phys.washington.edu/~ravel/software/exafs/packages/artemis_… If you are up to date with the most recent updater package, just download this executable and overwrite the "artemis.exe" file in the instalation directory: "C:\Program Files\Ifeffit" (or where ever you have ifeffit installed on your computer). -- 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

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

Question about the R_factor in artemis/ifeffit
by Wayne Lukens 28 May '04

28 May '04

Dear Matt and/or Bruce, First, thank you for the great software! I am a former EXAFSPAK user and have been really impressed by Artemis/ifeffit. It's easier to use, more flexible, and gives more reasonable errors for the fit parameters. My question is about the value of the R_factor for R-space fitting. This seems to be the R_factor for the real component of the Fourier transform only although the fitting is performed on both the real and imaginary components. Is there a reason that the contribution of the imaginary component to the R_factor is not included? Sincerely, Wayne --- Wayne Lukens Scientist Lawrence Berkeley National Laboratory email: wwlukens(a)lbl.gov phone: (510) 486-4305 FAX: (510) 486-5596

4 14

RE: Using more than one E0 correction
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 J 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: wojciech.gawelda(a)epfl.ch WWW: http://lsu.epfl.ch ********************************************************************* -----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: jeudi, 27. mai 2004 18:46 To: ifeffit(a)millenia.cars.aps.anl.gov Subject: Ifeffit Digest, Vol 15, Issue 23 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: Autobk parameters (Kelly, Shelly D.) 2. Re: Autobk parameters (Bruce Ravel) 3. Re: Autobk parameters (Stefano Ciurli) 4. Re: Autobk parameters (Stefano Ciurli) 5. A saving problem in newest Artemis version (Aria) ---------------------------------------------------------------------- Message: 1 Date: Wed, 26 May 2004 12:18:01 -0500 From: "Kelly, Shelly D." <SKelly(a)anl.gov> Subject: RE: [Ifeffit] Autobk parameters To: "XAFS Analysis using Ifeffit" <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <1C1577844A0BDF448E14E8CCB2F7442401006AF1(a)ANLMAIL.anl.gov> Content-Type: text/plain; charset="us-ascii" Hi Stefano, > 1) I understand that energy calibration should be performed, and I > did so by using the atomic edge energy. I also understand that this > parameter could be fluctuating in the subsequent fitting. Any comment > on this procedure? I agree that all the energy shift stuff can be confusing. The important end result for Extended X-ray Absorption Fine Structure Analysis is to get the energy-grid of the data to match the energy-grid of the theory with the zero energy of the photo-electron somewhere on the absorption edge. In the process of doing this you may have more than one data set from the same sample with different energy-grids... Furthermore you may have more than one sample which may have different energy-grid from the other samples and the theory. Then to make things all the more complicated X-rays can change the oxidation state of metals in organic materials. So that the energy grid is supposed to be different and the data is useless. After all that, here are some answers. 1) Always measure a foil reference at the same time that you measure any EXAFS data. It is easy to do. Here is a reference for how to do it when your sample is too thick and you can not simply put the foil behind the It ion chamber. J L Cross and A I Frenkel. "Use of scattered radiation for absolute energy calibration." Rev. Sci. Instrum. 70: pp 38-40, 1998 2) Align each data scan: 2a) Without an energy reference. Align the data to one of the data sets (remember which one you used) so that the edges are all right on top of each other. Each sample has it's own energy-grid. 2b) By using the energy reference of the foil measured simultaneously with each scan. Align all the reference spectra to one of the reference spectra. Then shift each of the data sets that belong to the reference spectra by the same amount. Now each scan is independently aligned and you have an absolute energy reference for each scan. This is useful for XANES comparisons or if you suspect changes in the data while the measurement was taking place. The difference in energy from the reference to the data or from one data set to another is a real change and can be used to "say" stuff about the sample. 3) Check the alignment: Plot all the normalized xmu(E) data from the same sample in Athena, zoom in on the edge region -20 to 20 eV and take a good look. Hopefully they all line up. If there is a systematic change in the edge features? If so how much...less than 10 % (which is about the accuracy of the measurement). This means that you can most likely still use the data but that you have changes happening to your sample while the measurement was taking place and you should fix that next time. 4) Now the problem of alignment is somewhat smaller. All the data sets have the same energy grid if you used 2b...or all the data sets have there own energy grid if you used 2a. Now we need to align the data and the theory. To do this there are two steps. Choosing a zero energy of the photo-electron to define the k-grid in converting the data to chi(k), and then aligning the chi(k) data with the theory chi(k). 5) Choosing a Ezero in Athena: Pick any point that you like on the edge for Ezero in Athena. Plot the xmu data with the background and pre-edge and post-edge range. A circle on the plot shows the position of Ezero. Then right click The Ezero to set this energy to be the same value for all the data sets from this sample. Then plot the chi(k) data and see that the curves all look the same at low k-values. If not adjust Ezero a bit for the data sets that are different to get the chi(k) data to look the same. Then average the chi(k) data and write it out so that you can align it with the theory in Artemis. 6) Aligning data to theory: Read the data into Artemis. Read in what you think should work for a first shell feffxxxxx.dat file. Fit the data to the first shell. Plot the data and the theory in chi(k), take a look at the deltaE value from the fit. This value for deltaE is telling you how much the theory had to move to match-up with your choice of Ezero that you picked in step 5. If you think that the theory is correct and deltaE is larger than a few eV then you need to adjust your chi(k) data. But first write out what the theory should look like if you choose Ezero just right. 6b) Making a standard: In Artemis, set all the parameters to their best-fit values, except for deltaE. Set deltaE to zero and run the fit again. This is not really a fit. There are no parameters to optimize. Now the theory is showing you what the data should look like if you choose the perfect value for Ezero and the perfect background function in step 5. 7) Redo the background and energy choice: In Athena open up the chi(k).fit that was produced by step 6b. This is the "standard" that you can use to help get Ezero and the background correct. Then select individual scans taken from the sample and then open the standard menu and choose the theory chi(k) data. Right click on the standard to use the same standard for all data sets. Redo the background removal. Plot the chi(k) data and the standard. If they are different at low k you need to adjust Ezero so that they start at the same place. When you are done adjusting your choice for Ezero, plot the xmu(E) data and make sure that the circle that is your value for Ezero is on the edge. If it isn't, then the theory that you used to align the data doesn't work..and you need to start over in step 6. If the value is on the edge some where, right click on the Ezero choice and set its value for Ezero of all the scans. Then merge all the data in chi(k) and write it out for use in Artemis...as you did the first time making sure that all the scans have a similar bkg. 8) Redo the fit: Now the data and the theory are aligned and you can redo the fit varying all the parameters...deltaE in Artemis should be small..and the background should give a nice match at low-r values. Often this entire procedure is used at the end of your analysis to make a nice figure for publication. 9) Bonus of using an energy reference: If you used an energy reference measured simultaneously with the data sets then in the end you can simultaneously fit the different samples with only one deltaE in the fit for all of the samples. If you aligned each one independently then each data set should have it's own deltaE value..unless you have more information and can prove that they should be the same. HTH Shelly ------------------------------ Message: 2 Date: Wed, 26 May 2004 16:56:37 -0400 From: Bruce Ravel <ravel(a)phys.washington.edu> Subject: Re: [Ifeffit] Autobk parameters To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <200405261656.37396.ravel(a)phys.washington.edu> Content-Type: text/plain; charset="iso-8859-1" Okee dokee, a few more thoughts after Matt's and Shelly's posts... SC> 2) The next parameter is Rbkg. I have read the literature about this SC> parameter, especially the 1993 paper by Matt. I sort of understood SC> the rationale and method, but I also gathered that the default SC> parameter of 1.0 can be changed. What are the criteria for changing SC> this? I tend to keep it to the default value, but I feel a bit uneasy SC> about not being able to control this parameter intelligently. Unfortunately there is not a really good rule of thumb. One might say "half the distance to the first peak", but that's not really a very good rule. The issue is that choice of Rbkg can have a profound impact on the low frequency Fourier components. (Try setting Rbkg to an absurdly large value, say 2 or 3, and see what damage that does to your data!) I would say the real answer is that the choice of Rbkg shouldn't be too strongly correlated with the things you are trying to measure -- N, delta_R, sigma^2. Once you have set up your fitting model in Artemis, a little experiment to try is to save chi(k) using several different values of Rbkg and see how the answers change when you do the fits. To completely make up an example, suppose that you save chi(k) for Rbkg=0.75 and 0.95, then do the fits. If the best fit values of N, delta_R and so on are the same within their error bars, then it doesn't matter which Rbkg you use in Athena. In that case you would probably use the larger one because it probably makes the "prettier" picture in terms of removing very low frequency Fourier components. SC> 3) I understood from the paper by Matt (and from the "Using Athena" SC> manual by Bruce) that one could use a "standard" to estimate the SC> level of leakage into the small chi(R) region (apodization effects SC> due to Fourier window filtering). The manual states that one can read SC> in a chi.dat file produced with feff. However, I do not understand SC> how to build the feff.inp for feff and produce a useful chi.dat to SC> use as a "standard". Please help? In your follow-up to my original answer to this question, you made it clear that the role of the standard is still not clear to you. As Matt said, the standard need not be perfect. Let me explain why. The autobk algorith works by "optimizing" the low frequency Fourier components in order to select the correct spline function. In the absence of a standard, "optimize" means "minimize". That is, without a standard, autobk finds the spline that makes the chi(R) spectrum as small as possible between 0 and Rbkg. Again as Matt said, low Z ligands often benefit by using a standard. The reason is that low Z ligands tend to have quite short distances resulting in a peak in chi(R) that has a significant tail into the region below Rbkg. In that case, *minimizing* the components between 0 and Rbkg is a poor idea because they are *supposed* to be non-zero. A standard then is used to tell the autobk algorithm what the components between 0 and Rbkg are supposed to look like and the spline is chosen to make the data look that way between 0 and Rbkg. In that context, the standard need not be perfect -- close should be good enough. Oh yeah. The feff run should produce a file called "chi.dat". That's a good one to use as a standard. Matt's ifeffit recipe for converting a feffNNNN.dat file into a chi(k) works, too. SC> 4) Then there is the k-weight parameter to be changed for the SC> background removal. The default value for this is 1, but higher SC> values are allowed. I noticed that increasing the k-weight for SC> background removal produces a curve in the chi(E) which more and more SC> appear to disregard the edge peak, resembling more and more a SC> smoothly monotonically increasing curve. Consequently, the chi(k) SC> changes depending on this parameter, and I again start to be worried SC> about the following fit of it. What are the criteria to choose this SC> k-weight for the background? With noisy spectra, the high energy portion of the data might be dominated by fluctuations that have nothing to do with the exafs. In that case a large k-weight for the background removal might be unduly influenced by stuff that is not the data you want to analyze but instead are detector problems, sample inhomogeneity problems, gremlins, crap, whatever ;-) SC> 6) Spline range: this is another important issue, I think. In the SC> paper by Matt it is stated that "standard practice ... has been to SC> ignore everything below an energy typically 30 eV above the E0" and SC> that Autobk is an advantage because it can read in data very close to SC> the E0. My question is: the default value for k in the spline range SC> is set to 0.5 eV (0.952 eV). What are the criteria to change this SC> default value? Also, is there any relationship between this range and Matt said: MN> I typically use kmin=0, kmax=last_data_point, dk=0 for the spline MN> (which are the defaults). Bruce seems to prefer kmin=0.5 or so: MN> it shouldn't make a difference. The reason I chose to make 0.5 the default is so that Athena will stand a better chance of dealing well with data that have a large white line. For data like that spline_kmin=0.0 often leads to a poor background removal because the spline just doesn't have the freedom to deal with such a quickly changing part of the spectrum. For many materials 0.0 is probably a better choice, but in Athena I want the default behavior to always be non-stupid. ("Smart" is a bit too difficult for me ;-) SC> the range subsequently used for FT? My guess is that the k-min for FT SC> should be always higher that the k-min for the spline range, but SC> please comment on this. Also, what are the criteria to set the Well, the FT range must be equal to or smaller than the spline range, but you probably already figured that out! Other than that there is not relationship. It is certainly useful in practice for them not to be the same. Getting back to the problem of deling with a white line, I often find it useful to make spline_kmin 1 or even larger to avoid the white line altogether. That means that the FT range will also be smaller resulting in less data for fitting, but it seems worth it. Since it is so hard to distinguish data from background under the white line, it is often better to just avoid the problem altogether. SC> 7) for the FT parameters: Shelly's protocol to define the k-range to SC> best calculate the chi(R) was clear and useful to me. However, I SC> would like to know more about choosing the dk parameter and the SC> window-type. I need some general criteria to choose between the SC> various possibilities. I noticed that the kaiser-bessel window is SC> the default, but in the literature I almost invariably find the SC> Hanning window. Please comment. Matt summed this up. (I liked the historical context!) Here is a talk that Shelly gave last year at the NSLS exafs course: http://cars9.uchicago.edu/xafs/NSLS_EDCA/July2003/Kelly.pdf Check out page 21. It demonstrates really clearly how little the choice of window shape matters. As for dk, I don't have a good rule of thumb. I generally choose a smallish number. I wanted also to say a few words about your question regarding peak fitting. In a numerical sense, peak fitting is harder than fitting exafs spectra. An exafs spectra is basically one or more damped sine waves. If you try to fit that with any ol' damped sine wave that's not too far out of phase, you won't go too far wrong. The same is not true of fitting peak shapes to xanes data. That kind of non-linear fit is notoriously unstable. In my experience, it can be very difficult to fit the centroid of a peak shape to a feature in a xanes spectrum. That is why Athena has the centroid not flagged as a variable by default. I am not completely clear on what's going on with your data, but it seems as though you want to fit a very tiny feature at the very beginning of the data. The problem there is that, if the pre-edge is not completely flat, the lineshape used for the edge step might through the peak or well below the peak. If so, the peak shape you are trying to use to fit that feature might be poorly defined numerically. I would recommend trying to adjust the parameters by hand until you geta fairly decent representation of the data, then let some of the parameters float in a fit to start understanding where the parameters will want to float off to. If you try to fit the whole xanes spectrum in one quick swoop, though, you are indeed likely to get a poor fit. SC> I feel like a naive cook who is afraid of making mistakes, and SC> therefore reads a receipe very carefully, not to mix the wrong SC> ingredients in the wrong amounts. So, again, please bear with me. Well, I have enjoyed cooking my entire life and I like to think I am not so bad at it. In my experience, the one way to truly learn how to make a really good dish is to make some bad ones and think about what went wrong. You'll know when you're getting there because the dish will start to taste good. The same applies to using the codes. Poke at the buttons and don't fret if weird stuff happens. Think about what it means and why the weird results are inconsistent with what you know about your sample. Eventually the results from the analysis will start to make sense in the context of what you know about your samples. Mmmmmm.... that's good analysis! 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/ ------------------------------ Message: 3 Date: Thu, 27 May 2004 15:21:49 +0200 From: Stefano Ciurli <stefano.ciurli(a)unibo.it> Subject: Re: [Ifeffit] Autobk parameters To: ravel(a)phys.washington.edu, XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <a06100508bcdb9b73cde8(a)[137.204.93.158]> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Bruce, >SC> 4) Then there is the k-weight parameter to be changed for the >SC> background removal....What are the criteria to choose this >SC> k-weight for the background? > >With noisy spectra, the high energy portion of the data might be >dominated by fluctuations that have nothing to do with the exafs. In >that case a large k-weight for the background removal might be unduly >influenced by stuff that is not the data you want to analyze but >instead are detector problems, sample inhomogeneity problems, >gremlins, crap, whatever ;-) so I conclude that I should use a LOW k-weight in my case, right? 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 ------------------------------ Message: 4 Date: Thu, 27 May 2004 15:18:21 +0200 From: Stefano Ciurli <stefano.ciurli(a)unibo.it> Subject: Re: [Ifeffit] Autobk parameters To: ravel(a)phys.washington.edu, XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <a06100507bcdb99ed729e(a)[137.204.93.158]> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi Bruce, >Oh yeah. The feff run should produce a file called "chi.dat". That's >a good one to use as a standard. Matt's ifeffit recipe for converting >a feffNNNN.dat file into a chi(k) works, too. when I run feff, I do not get any chi.dat file. Why? I tried to use artemis to do that, but right now the new version I installed crashes when I try to read in a feff calculation (which btw I performed on something that should be similar to my metal site and was about to use it for standard...) The trap message states: # Artemis 0.7.004 # This file created at 12:59:30 on 27 May, 2004 # using darwin, perl 5.008001, Tk 804.027, and Ifeffit 1.2.5 # Workspace: /Users/stefano/.horae/stash/artemis.project.0/ The following message was trapped by Artemis on a SIGDIE: Artemis0.7.004die/Users/stefano/.horae/stash/ARTEMIS.TRAPCODE(0x1e38760) /Users/stefano/.horae/stash/artemis.project.0/ at /Applications/Ifeffit/bin/artemis line 1550 main::__ANON__('Callback called exit.\x{a}') called at /Applications/Ifeffit/bin/artemis line 0 Stefano PS: I am using the OSX 10.3 version -- ____________________________________________ 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 ------------------------------ Message: 5 Date: Thu, 27 May 2004 12:46:39 -0400 From: "Aria" <fyang(a)ECE.NEU.EDU> Subject: [Ifeffit] A saving problem in newest Artemis version To: <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <000001c4440a$2e89efd0$443d0a81@harrispc> Content-Type: text/plain; charset="us-ascii" Hi folks, First, thank Bruce and Matt so much for their non-stopping work in updating those beautiful pieces of software. Somehow, another problem occurred to me after the auto-updating days ago. I am not sure if this only happened to me. Artemis so far has no problems in dealing with those project files which were created by the old versions. But when I tried to create a new project importing more than one FEFF calculations, after I saved and tried to reload it, Artemis simply failed to do so. The only FEFF path showed in the 'Data & Paths' panel is the first path in the first FEFF calculation. This is the message I copied from echo: Opening project zipfile C:/.../artemis60mT_C_100 ... Opening project zipfile artemis60mT_C_100 ... done! Doing intrp for CuOct ... Doing intrp for CuOct ... done! Artemis trapped a warning! Message dumped to C:\Program Files\Ifeffit\horae\stash\ARTEMIS.TRAP The artemis.trap files is shown as below: # Artemis 0.7.004 # This file created at 12:28:24 on 27 May, 2004 # using Windows XP, perl 5.006001, Tk 800.024, and Ifeffit 1.2.5 # IFEFFIT_DIR is C:\Program Files\Ifeffit # Workspace: C:\Program Files\Ifeffit\horae\stash\artemis.project.1\/ The following message was trapped by Artemis on a SIGWARN: Artemis0.7.004warnC:\Program Files\Ifeffit\horae\stash\ARTEMIS.TRAPCODE(0x3372680)C:\Program Files\Ifeffit\horae\stash\artemis.project.1\/ at artemis line 1551 main::__ANON__('Tk::Error: could not open C:\Program Files\Ifeffit\horae\stash\a...') called at blib\lib\Tk.pm (autosplit into blib\lib\auto\Tk\Error.al) line 402 Tk::Error('MainWindow=HASH(0x387c174)', 'could not open C:\Program Files\Ifeffit\horae\stash\artemis.proj...', '[\&main::dispatch_read_data]', '(menu invoke)') called at /PerlApp/Tk.pm line 340 eval {...} called at /PerlApp/Tk.pm line 340 Tk::MainLoop() called at artemis line 1695 When I click on the only path, another warning is trapped: # Artemis 0.7.004 # This file created at 12:39:51 on 27 May, 2004 # using Windows XP, perl 5.006001, Tk 800.024, and Ifeffit 1.2.5 # IFEFFIT_DIR is C:\Program Files\Ifeffit # Workspace: C:\Program Files\Ifeffit\horae\stash\artemis.project.1\/ The following message was trapped by Artemis on a SIGWARN: Artemis0.7.004warnC:\Program Files\Ifeffit\horae\stash\ARTEMIS.TRAPCODE(0x3372680)C:\Program Files\Ifeffit\horae\stash\artemis.project.1\/ at artemis line 1551 main::__ANON__('Use of uninitialized value in split at artemis line 5800, <PROJ>...') called at artemis line 5800 main::populate_path('data0.feff0.0') called at artemis line 2475 main::display_properties('Tk::Ev=SCALAR(0x3327260)', 'data0.feff0.0', 0, 'imagetext', 'body') called at /PerlApp/Tk/Widget.pm line 988 eval {...} called at /PerlApp/Tk/Widget.pm line 988 Tk::Widget::Callback('Tk::Tree=HASH(0x32d2c3c)', '-browsecmd', 'data0.feff0.0', 0, 'imagetext', 'body') called at /PerlApp/Tk/HList.pm line 181 Tk::HList::Button1('Tk::Tree=HASH(0x32d2c3c)') called at /PerlApp/Tk.pm line 340 eval {...} called at /PerlApp/Tk.pm line 340 Tk::MainLoop() called at artemis line 1695 I am not sure the information is enough. Hope it helps. Best regards, Aria

2 1