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

Noisy spectrum and AUTOBK
by gabriel rosenblum 20 Apr '04

20 Apr '04

Hi all I have a question regarding noisy EXAFS, since I analyze biological zinc samples. I have seen Bruce�s data and it is quiet as a sleeping snail all the way till chi(k)=16, however I have a completely different situation since I encounter noise at high chi(k) and I need an advice from whoever can supply it. As I use AUTOBK with emax set to maximum I observe chi(k) which is quiet at 0-9, and at 9-12 I obsrerve clearly the oscillations but with the addition of small spikes resulting from noise. At chi (R ) I see the first shell peak at 1.5A with amplitude of 1. Adjacent to this peak I observe a small peak at 1A with 0.5 amplitude. As I change Rbkg and Knin I cannot get rid of the small peak; the left region of the small peak is situated between 0.5 to 1A at chi(R ), and my attempts to keep this region �clean� failed. However, if I lower emax to 400, corresponding to approx. 10 at chi(K), and fourier-transform the region between 2 to 9 (the quiet region), the small peak disappears and the region at Chi (R ) between 0 to 1A is �clean�, but since I utilize less information the peaks at chi (R ) have lower resolution. My questions are: 1. What is the source of the small peak ? 2. Is it a real contribution from scattering ligands ? 3. How should I treat the small peak. 4. Should I get rid of it by all means ? if so, how ? My confusion arises from the fact that AUTOBK should get rid of atomic exafs at chi(k), consequently, the contributions at chi (R ) between 0 to 1A should get lower. In my case it seems that this contribution is lower, but it still exist with half the amplitude of the first shell peak. Any help would be appreciated. Thanks. Gabi. __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

1 0

[proposal] Artemis plotting option
by mauro＠rulp.org 20 Apr '04

20 Apr '04

Hi, I would like to know if it is possible to include in Artemis the "stack" plotting option, like the Athena's one. In fact, setting a y-offset value for the selected chi/paths/residual could be very useful. Thanks, M -- Mauro Rovezzi <mauro(a)rulp.org> - Physics student University of Rome "Tor Vergata", ESRF Beamline BM8 - GILDA

2 1

S02-Interpretation
by Norbert Weiher 20 Apr '04

20 Apr '04

Dear Friends, I would like to ask a question on the interpretation of S02 in a fit. Although there has been some discussion on this parameter, I did not find exactly what I was looking for. Here it goes: To my knowledge, S02 accounts for intrinsic as well as extrinsic losses in the sample. Now, if I have two samples and determined the S02 value according to the way which Bruce has in his supplement to the FEFFIT course, I find two differing values for electrochemically prepared oxide (0.74) and crystalline gold oxide (0.92). This difference is independent of beamlines I measured and I can exclude quite safely that it is just a measurement error - it comes up with any spectrum I recorded on these systems. When discussing this with my colleagues, we interpreted the S02 difference as an indication of more disorder in case of the electrochemical system (which would well fit to my picture of the whole thing). BUT: Is there any physical reason to assign a difference in S02 (for "chemically equivalent" systems, where just the preparation is different) to a structural disorder? Regards, Norbert -- Dr. rer. nat. Norbert Weiher (weiher(a)chem.ethz.ch) Institute for Chemical and Bioengineering - ETH Hönggerberg HCI E 117 - 8093 Zürich - Phone: +41 1 63 3 48 32

3 3

Windows Update
by Matt Newville 19 Apr '04

19 Apr '04

Hi Folks, I've posted a windows update that includes Bruce's latest Athena, and Hephaestus, that he described a week ago. It also has a couple other fixes: - a problem with runprog.exe got fixed so that running autobk,feffit, and feff6 now works correctly for directories that contain a space in their name. - the updater now includes two additional parameters that may help those people who were having problems with the updater timing out before downloading files. These are both in updates\updater.ini: timeout_connect is the time in seconds to connect to to http://cars9.uchicago.edu to read what the update level is and verify that a connection can be made. timout_download is the time in seconds to download a zip file. If you have problems with the updater, try increasing these numbers from their default values of 60seconds and 2400seconds. Sorry for taking so long on this. --Matt

1 0

introducing Hephaestus ...
by Bruce Ravel 19 Apr '04

19 Apr '04

Hi folks, In his workshop he has handmaidens he has forged out of gold who can move and who help him in his work. ... With Athena, he [is] important in the life of the city. The two [are] the patrons of handicrafts, the arts which along with agriculture are the support of civilization. "Mythology", Edith Hamilton The big new feature in the latest release is a new program called Hephaestus -- in keeping with the Greek mythology theme. Hephaestus combines the functions of the old Atoms Periodic Table with a bunch of other small utilities based on the priodic table and on tabels of x-ray absorption coefficients. Hephaestus supercedes both the Atoms Periodic Table and the TkFormula programs, both of which are being retired. You should find that Hephaestus is a very handy tool both at home and at the beamline. Along with displaying edge and line energies, and computing absorption lengths of elements and compounds, Hephaestus offers tools for computing the absorption of ion chambers, displaying the anomalous scattering factors of the elements, and displaying chemical data about the elements. Here is a web page with descriptions and a few screenshots: http://leonardo.phys.washington.edu/~ravel/software/exafs/abouthephaestus.h… The Windows updater does not install shortcuts to the desktop or to the Start menu, so Windows users might want to do so by hand. The updater will put the hephaestus.exe and .bat files in the normal Ifeffit place and you will find the hephaestus.ico icon file there as well. It should be a simple matter to modify the desktop and Start menu shortcuts for the Atoms Periodic Table to launch hephaestus instead. If you do not know how this is done, post a question to the mailing list and hopefully someone will explain. For the unix users, there is an icon file for use on the desktop in the Ifeffit/lib/hephaestus directory when you unpack the source code tarball. The file vulcan.gif is the intended icon file. I hope that you will find Hephaestus useful and I look forward to hearing people's suggestions for improving it. 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 4

RE: [Ifeffit] S02-Interpretation
by Kelly, Shelly D. 16 Apr '04

16 Apr '04

Hi Matt > > Now, if I have two samples and determined the S02 value according to > > the way which Bruce has in his supplement to the FEFFIT course, > > How do you mean this? Is this the 'plot three curves of sigma2 v. > S02 curves for three different k-weights' again? I find this > approach puzzling and dangerous. I do not understand why the slope > (correlation) of sigma2 v. S02 should depend on k-weight in > any systematic way -- does anyone else know why it should?? > What you want is the S02 and sigma2 that gives the lowest > chi-square, not where these lines cross. I have found that usually there is a "larger than one would like" correlation between the amplitude and phase terms in the EXAFS equation. But the different terms have different k-dependencies. Low k-weights will give more weight to an accurate E0, whereas higher k-weights will give a more accurate deltar. Although the errors will be large. If you plot the dependence of these variables on the k-weight, or better yet use all three k-weights in the fit, you will find that the best-fit value is consistent with the one k-weight value but that the uncertainty is lower because you are distinguishing between the two coorelated variables by including the k-dependence in the fit. Shelly

3 2

[HELP!] Athena and Artemis doesn't start
by mauro＠rulp.org 16 Apr '04

16 Apr '04

Hi to all, This morning the "story" started with some .TRAP files during an Artemis fit. From one of this I have understood the problem was again with conflicts between the compiled-by-hand horae version and Carlo's .deb (automatically installed) package. Here the ARTEMIS.TRAP file: # This file created at 10:32:53 on 16 April, 2004 # using linux, perl 5.008003, Tk 800.025, and Ifeffit 1.2.5 The following message was trapped by Artemis on a SIGWARN: Artemiswarn/home/mauro/.horae/stash/ARTEMIS.TRAPCODE(0x95e0a4c) at /usr/bin/artemis line 1491 main::__ANON__('Use of uninitialized value in concatenation (.) or string at ...') called at /usr/bin/artemis line 5809 main::set_degeneracy(1) called at /usr/lib/perl5/Tk.pm line 225 eval {...} called at /usr/lib/perl5/Tk.pm line 225 Tk::__ANON__('Tk::Menu=HASH(0x96c8228)','active') called at /usr/lib/perl5/Tk/Menu.pm line 531 Tk::Menu::Invoke('Tk::Menu=HASH(0x96c8228)',1) called at /usr/lib/perl5/Tk.pm line 347 eval {...} called at /usr/lib/perl5/Tk.pm line 347 Tk::MainLoop() called at /usr/bin/artemis line 1627 After this, I decided to reinstall everything. I have completely removed the previous software from "/usr/local" and I have used apt-get to reinstall horeae and ifeffit (also). The result is: Artemis and Athena doesn't start! These the errors: mauro@mac6npd2:~$ artemis Can't load '/usr/lib/perl5/auto/Ifeffit/Ifeffit.so' for module Ifeffit: /usr/lib/perl5/auto/Ifeffit/Ifeffit.so: undefined symbol: PL_sv_undef at /usr/lib/perl/5.8/DynaLoader.pm line 225. at /usr/bin/artemis line 49 Compilation failed in require at /usr/bin/artemis line 49. BEGIN failed--compilation aborted at /usr/bin/artemis line 53. mauro@mac6npd2:~$ athena Can't load '/usr/lib/perl5/auto/Ifeffit/Ifeffit.so' for module Ifeffit: /usr/lib/perl5/auto/Ifeffit/Ifeffit.so: undefined symbol: PL_sv_undef at /usr/lib/perl/5.8/DynaLoader.pm line 225. at /usr/bin/athena line 55 Compilation failed in require at /usr/bin/athena line 55. BEGIN failed--compilation aborted at /usr/bin/athena line 59. I really don't know what to do. I've tried different times reinstalling the ..deb package o recompiling the source. Please, help me! -- Mauro Rovezzi <mauro(a)rulp.org> - Physics student University of Rome "Tor Vergata", ESRF Beamline BM8 - GILDA

4 8

Re[2]: a question about background refinement
by Stanislav Stoupin 16 Apr '04

16 Apr '04

To Matt: >Normally, you'd want to keep >Rbkg/Rmin below the 'first shell peak', which is sometimes difficult >to define for the asymmetric peak common with short metal-oxygen >distances, but if the peak is around 1.3Ang, the Rbkg/Rmin of 1.5Ang >seems like it might be too high. Can you get decent results with >a lower Rbkg/Rmin? No, I can not. 1.5A is around the minimum value in Chi(R) magnitude where the first peak can be separated from the others. However, the peak is a result of superposition of background, oxygen path and also the alloy structure. As for the correlation between Ru-O variables and the background parameters, they are somewhat correlated I think If I do not play with the rmin value and keep it equal to 1.0A these correlations are: delr_ru_o and bkg01_05 --> 0.5440 delr_ru_o and bkg01_04 --> -0.3878 dwf_pt_pt and bkg02_11 --> 0.3551 x_o and bkg01_01 --> -0.2856 delr_ru_o and bkg01_03 --> 0.2760 delr_ru_ru and bkg01_05 --> 0.2709 dwf_ru_o and bkg01_01 --> -0.2614 x_o and bkg01_02 --> 0.2600 dwf_ru_o and bkg01_02 --> 0.2595 delr_ru_pt and bkg02_11 --> 0.2562 x_o means the amplitude of Ru-O path e0 for Ru-O path is constrained to be the same as for all paths with Ru central atom To Jeremy: >You mention that the amplitude remains consistent at about 0.3. >However, what is happening to R and E0? Are these values also >reasonable? I have found that, on occasion, a negative DWF is telling >me that oxygen may not be the correct nearest neighbor. In these cases, >R and E0 are always anomalous for the metal-oxygen path. I have two e0 parameters in the model that correspond to ru and pt data sets (they are e0_ru and e0_pt) the same e0_ru I use for Ru-O path Typical values that they take are about: e0_pt = 7.2318013 +/- 1.0171952 (0.0000) e0_ru = -9.1526876 +/- 0.7730603 (0.0000) and this is consistent through all data that I have and also their values almost do not depend on whether I use rmin=1.0A or 1.5A the same I can say about Ru-O distance. Typical value is: delr_ru_o = -0.0899771 +/- 0.0406058 (0.0000) To Bruce: >I have a question for you. Are you trying to determine the oxide >content? That is, do you want to know what fraction of the Ru atoms >are in an oxide environment? Or are you trying to account for the >oxide so that you better measure the metallic component? My advisor (Carlo Segre) has already answered this question I just want to add that the observed amplitude of Ru-O path (0.3)is approximately in agreement with the number of atoms on the nanoparticle surface. This may indicate that all Ru atoms are on the surface and all they have oxygen bonds. Stanislav

4 7

RE: [Ifeffit] crucial information
by SCHLEGEL Michel 177447 15 Apr '04

15 Apr '04

> the correct greek prononciation were > "hephaistos" which is the god of "smiths" > But this is from "old Europe", Yep, and he was the unfortunate husband of Venus. So Bruce, if you are planing some versatile companion software for "Hephaistus"... Best regards, Michel Schlegel

2 1

RE: [Ifeffit] crucial information -oops
by SCHLEGEL Michel 177447 15 Apr '04

15 Apr '04

oops.. sorry, it's the Greek goddess Aphrodite > -----Message d'origine----- > De : SCHLEGEL Michel 177447 > Envoyé : jeudi 15 avril 2004 15:04 > À : 'XAFS Analysis using Ifeffit' > Objet : RE: [Ifeffit] crucial information > > > > > the correct greek prononciation were > > "hephaistos" which is the god of "smiths" > > But this is from "old Europe", > > Yep, and he was the unfortunate husband of Venus. > So Bruce, if you are planing some versatile > companion software for "Hephaistus"... > > Best regards, > > Michel Schlegel > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >

1 0

crucial information
by Bruce Ravel 15 Apr '04

15 Apr '04

Hey, I've now been asked several times how to pronounce the word "Hephaestus". Although I am fairly confident that each of the people who asked owns a dictionary, here's some linkage to Merriam-Webster. The page includes a .wav file of someone saying it (click on the little red speaker icon). http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=hephaestus&x=0&y=0 ;-) 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

"FEFFs order" bug corrected in Artemis 0.7.003
by Stanislav Stoupin 15 Apr '04

15 Apr '04

From: Bruce Ravel <ravel(a)phys.washington.edu> >BTW, Does the new release of Artemis seem to address the many problems >you reported with your multiple data set, multiple feff calculation >fits? It does! I have just performed a couple of tests where I opened old-style project that had "incorrect" FEFF order: data_set1 FEFF0 FEFF1 FEFF4 data_set2 FEFF2 FEFF3 test #1 1. fit the data and saved as another project 2. opened the saved project no missing FEFFs were found nothing changed test#2 1. change data in the project 2. fit and saved as another project 3. opened the saved project again no missing FEFFs were found and no other suspicious behaviour was observed These things did't work before Stanislav

1 0

RE: [Ifeffit] S02-Interpretation
by Kelly, Shelly D. 14 Apr '04

14 Apr '04

> To my knowledge, S02 accounts for intrinsic as well as > extrinsic losses in the > sample. Now, if I have two samples and determined the S02 > value according to > the way which Bruce has in his supplement to the FEFFIT > course, I find two > differing values for electrochemically prepared oxide (0.74) > and crystalline > gold oxide (0.92). This difference is independent of > beamlines I measured and > I can exclude quite safely that it is just a measurement > error - it comes up > with any spectrum I recorded on these systems. > > When discussing this with my colleagues, we interpreted the > S02 difference as > an indication of more disorder in case of the electrochemical > system (which > would well fit to my picture of the whole thing). > > BUT: Is there any physical reason to assign a difference in S02 (for > "chemically equivalent" systems, where just the preparation > is different) to > a structural disorder? > > Regards, > > Norbert Hi Norbert, I believe that the value for S02 should be the same in these two samples. But S02 is not the only amplitude term in the EXAFS equation. The degeneracy of the path, sigma2, and the step height normalization are also amplitude terms. One needs to be careful in processing the data so that the change in the amplitude between the two signals really belongs to the correct parameter. Here is a recipe for how I would try to solve the problem: 1st: Double check the step height normalization in Athena. 1) Make sure that Ezero is the same for both data set and that the data sets are aligned in energy. 2) Plot the xmu data along with the pre-edge and post-edge lines and check the step height that Athena reports...make sure it seems reasonable. 3) plot both chi(k) data sets with kweight of 1, and then 2 and then 3. You are looking to see if the change in amplitude between the data sets is the same for all k-range or if the ampliude changes more at high or low k. 4) you could also Fourier filter the data and do this again. If the change in amplitude is the same for all k, then the difference is because of SO2 or degeneracy or step height normalization. If the change in amplitude is more at high k than at low k the change is because of sigma2 term. If the change is more at low k than at high k then I would say different bkg curves or self absorption effects. 2nd: Say you think that the difference is due to a sigma2 term. I would fit both data sets with the same parameters for SO2 and different parameters for sigma2 for what ever paths you decide to include in your fit. If you want to prove that the change is a sigma2 and not a SO2 parameter then you do the fit using kweight of 1, and 2 and 3 all at the same time for both data sets, trying two different models, 1) where SO2 is different for both data sets but sigma2 is the same, and 2) another where sigma2 is different but SO2 is the same. You should see a difference in the goodness-of-fit parameters that is greater than one standard deviation. Using all three k-weights helps Artemis "see" the changes that you saw in Athena, by comparing the two data sets with the different k-weights. I just read Bruce's comment, If you think that the change should be in the coordination number then you should repeat the above models with the coordination numbers allowed to vary. To decouple SO2 and N you need to have more than one shell in the fit, otherwise they are exactly the same variable. H.T.H Shelly

1 0

new Debian packages of horae-033
by Carlo U. Segre 14 Apr '04

14 Apr '04

Hello All: There are now new Debian packages of the latest horae available. Bruce, I noticed that you removed tkformula and apt in favor of the new combined application called Hephaestus. Hopefully I didn't miss any other big changes in the programs. The sources and binaries can be obtained at For the stable (woody) distribution deb http://fermi.phys.iit.edu/debian/woody binary/ deb-src http://fermi.phys.iit.edu/debian/woody source/ For the unstable (sid) distribution deb http://fermi.phys.iit.edu/debian/sid binary/ deb-src http://fermi.phys.iit.edu/debian/sid source/ Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 segre(a)agni.phys.iit.edu http://www.iit.edu/~segre

3 6

a question about background refinement
by Stanislav Stoupin 13 Apr '04

13 Apr '04

Hello all, Recently, I was able to improve fitting results in one of my projects using background refinement/subtraction in some "strange" way. I have got reasonable results but I was not totally sure if that was a valid approach. So, any feedback is appreciated. Here is the story: The system I am working on is Ru-Pt fcc alloy in a form of nanoparticles which may be oxidized. There is a reason to suspect presence of Ru-O bonds in the system. For the moment I am doing only the first shell analysis and the model I am using includes a part that models alloy first shell structure and also Ru-O path. If I don't use the Ru-O path in my model all the alloy parameters that I get from the fit are reasonable but the fit works bad in low R region. In that region there is a broad peak around 1.3A. The rmin parameter which is responsible for background refinement is set to 1A ( the same value was used when I did initial background subtraction in Athena). What I found a long time ago is that the fit could be significantly improved if I add the Ru-O path in my model (all alloy parameters were even better in that case). However, the DWF of Ru-O bond always went negative (about -0.005). At the same time I got reasonable value for the Ru-O amplitude which was about 0.3. I attempted to get rid of the negative DWF value many times. For example, if I fixed or restrained the DWF to a reasonable value (0.01 is what I expect) it didn't help. Finally, I decided to play with background refinement and what I have done can be described as follows: 1. Set rmin to about 1.5 A 2. Fit with my model which included Ru-O path with fixed delr = 0 and DWF = 0.01 ( the Ru-O amplitude was allowed to vary). Backgound fitting was turned on. 3. Subtracted the background from the data 4. Moved rmin back to 1A and allowed Ru-O delr to vary (the DWF remained fixed to 0.01) 5. Fit again with no background fitting A very decent looking fit came out as a result. (Chi-square was improved) The Ru-O amplitude was about 0.3 (as expected) and I had the DWF set to 0.01. Thanks for you patience if you read it all the way through. My own impression of what I have done is that it looks very artificial and the fact that I use AUTOBK two times bothers me a lot. The second time it is supposed to remove all structural information below 1.5A (rmin value). However, with this approach I hope to get rid of the background that dominates the fine structure in the low R region (Ru-O scattering) using some preliminary knowledge about the compound. I will be happy to hear any point of view. Thank you in advance. If you are interested and want more details please let me know. Stanislav -------------------------------- Stanislav Stoupin Research Assistant/PhD student BCPS Department Illinois Institute Of Technology E-mail:stousta@iit.edu

4 3

RE: [Ifeffit] a question about background refinement
by Kropf, Arthur Jeremy 13 Apr '04

13 Apr '04

Stanislav, You mention that the amplitude remains consistent at about 0.3. However, what is happening to R and E0? Are these values also reasonable? I have found that, on occasion, a negative DWF is telling me that oxygen may not be the correct nearest neighbor. In these cases, R and E0 are always anomalous for the metal-oxygen path. Jeremy Kropf Chemical Engineering Division Argonne National Laboratory -----Original Message----- From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of Stoupin, Stanislav A. Sent: Tuesday, April 13, 2004 5:01 AM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: [Ifeffit] a question about background refinement Hello all, Recently, I was able to improve fitting results in one of my projects using background refinement/subtraction in some "strange" way. I have got reasonable results but I was not totally sure if that was a valid approach. So, any feedback is appreciated. Here is the story: The system I am working on is Ru-Pt fcc alloy in a form of nanoparticles which may be oxidized. There is a reason to suspect presence of Ru-O bonds in the system. For the moment I am doing only the first shell analysis and the model I am using includes a part that models alloy first shell structure and also Ru-O path. If I don't use the Ru-O path in my model all the alloy parameters that I get from the fit are reasonable but the fit works bad in low R region. In that region there is a broad peak around 1.3A. The rmin parameter which is responsible for background refinement is set to 1A ( the same value was used when I did initial background subtraction in Athena). What I found a long time ago is that the fit could be significantly improved if I add the Ru-O path in my model (all alloy parameters were even better in that case). However, the DWF of Ru-O bond always went negative (about -0.005). At the same time I got reasonable value for the Ru-O amplitude which was about 0.3. I attempted to get rid of the negative DWF value many times. For example, if I fixed or restrained the DWF to a reasonable value (0.01 is what I expect) it didn't help. Finally, I decided to play with background refinement and what I have done can be described as follows: 1. Set rmin to about 1.5 A 2. Fit with my model which included Ru-O path with fixed delr = 0 and DWF = 0.01 ( the Ru-O amplitude was allowed to vary). Backgound fitting was turned on. 3. Subtracted the background from the data 4. Moved rmin back to 1A and allowed Ru-O delr to vary (the DWF remained fixed to 0.01) 5. Fit again with no background fitting A very decent looking fit came out as a result. (Chi-square was improved) The Ru-O amplitude was about 0.3 (as expected) and I had the DWF set to 0.01. Thanks for you patience if you read it all the way through. My own impression of what I have done is that it looks very artificial and the fact that I use AUTOBK two times bothers me a lot. The second time it is supposed to remove all structural information below 1.5A (rmin value). However, with this approach I hope to get rid of the background that dominates the fine structure in the low R region (Ru-O scattering) using some preliminary knowledge about the compound. I will be happy to hear any point of view. Thank you in advance. If you are interested and want more details please let me know. Stanislav -------------------------------- Stanislav Stoupin Research Assistant/PhD student BCPS Department Illinois Institute Of Technology E-mail:stousta@iit.edu _______________________________________________ Ifeffit mailing list Ifeffit(a)millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

1 0

[Ifeffit] Re: from I.Demchenko (PhD student at the Institute of Physics PAS)
by Bruce Ravel 07 Apr '04

07 Apr '04

Hi Iraida, I hope you don't mind that I CC my reply to the ifeffit mailing list. I have some suggestions for you, but I thought it might be helpful to you to see if anyone else has anything to contribute. (The attachments to Iraida's email included a couple of screenshots showing the plotting window with a very good-loooking fit. She also sent the artemis log file showing many of the numbers she quotes below.) On Tuesday 06 April 2004 12:12 pm, Iraida Demchenko wrote: > I have a problem with fitting of my data for 0.5 microns of Ge on > Si(001) substrate (grown by MBE). The spectrum for K-edge of Ge was > collected by TY mode. This sample is a standard for my next > fitting. >From this fitting (for 1 shell) I want to draw > So^2... But, if I apply a "trick" with k-weight determination as 1 > and So^2 value changing from 0.7 to 1.1 and repetition of this > operation for k^1, k^2, k^3, I get three parallel lines for > sigma^2(Ge-Ge) as function of So^2 :(. They aren't crossed in this > area. This is kind of surprising to me. I have used the three-lines trick many times and have never seen the situation of three parallel lines. I am a little confused how that is even possible. One might expect this trick to do strange things in the case of a first shell that is not well separated from higher shells, but my memory of Ge is that the first shell is well separated. Another situation that might lead to trouble is if strain induced by the substrate splits the first shell into two well-separated peaks. However, that does not seem to be the case for you either. 1/2 micron is (I think) thick enough so that the film should be bulk-like. Sadly, I am stumped. Has anyone else ever seen this? > On the other hand, I tried to fit my data (3 shells, k-w=2; dk=2; > Hanning; k(3.5-12.3)) and I've obtained: reduced chi-square=10.33; > R-factor=0.011; So^2=1.22 +/- 0.34; dr_1=0.0107+/-0.006; > sigma^2_1shell=0.0037+/-0.0019; sigma^2_2=0.0068+/-0.0033; > sigma^2_5=0.0096+/-0.0041(3 shell) (of course, that errors were > recalculated(following FEFFIT, p.44). I doubt about the obtained > value for So^2=1.22 +/-0.34. Within the error, of course, I can say, > that this value is in the range from 0.6 to1. But, the correlations > between variables are: amp (So^2) and sigma2_1: 0.916 :(; amp and > sigma^2_2: 0.498; amp and sigma^2_5: 0.49; sigma^2_1 and sigma^2_2: > 0.47; sigma^2_1 and sigma^2_5: 0.45.....all other correlations are > below 0.25. In the attachment there is a log file for this fitting, > as you can see sigma^2_3 is -0.0055+/-0.016 :(. > > Are there any other ways to determine our So^2? Or these actual results > (So^2=1.22) we can consider as good? What do You think about this fit? First, as you say, your value for S02 is not unreasonable in that the error bar covers a value that one might expect. Still, you are right that 1.22 is an oddly large best fit value and suggests that something else might be happening in the data. Second, I wouldn't be so concerned about the high correlation between S02 and sigma^2. It's normal. Here is a nice short piece by Matt about correlations: http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2004-February/000713.html The rest of thread might be of interest to you, as well. At another point in that thread, there is some discussion of how the normalization is done. Have you examined that carefully? If the post-edge line intersects E0 at an oddly low value, then the edge-step used in the normalization might be rather too small. This is certainly a possibility in fluorescence data where the region after the edge sometimes sweeps upward. In that case, the normalization range is such that the regressed post-edge line can be below the data near E0. I explained this in some more detail at http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2004-February/000711.html That could be the cause of a best-fit S02 that is larger than 1, That's my best guess, given that I have not seen the mu(E) data, for what is happening. I was bit confused by thing about sigma^2_3. I saw in the log file that it was, as you said, negative. But none of the sigma^2 values for the paths were negative. It wasn't clear how that sigma^2 value was being used. Hope that helps, B P.S. I could tell from the log file that you sent me that you are using a *very* old version of Artemis and presumably of ifeffit as well. You may want to download the latest ifeffit installation package from http://cars9.uchicago.edu/ifeffit/download.html and then let the automatic updater bring your computer completely up to date. -- 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 2

simultaneous fitting of multiple data sets in ifeffit
by Stanislav Stoupin 05 Apr '04

05 Apr '04

Hello! First of all I would like to thank Bruce for answering my questions. As a beginner I very much appreciate your help. Now I am trying to compare my results using two possible ways of doing EXAFS analysis : 1. Artemis 2. ifeffit command line (loading input files) Here is my question: When I use ifeffit commands it is not clear to me how to assing different kmin/kmax (rmin/rmax) values to different data sets in a multiple data set fit. My current understanding of the problem is as follows: As ifeffit documentation says all variables are global. At the same time ifeffit tries to evaluate all parameters of feffit() command first and does the fit only after determination of kmin kmax rmin rmax. What happens is that the last given values are assigned to these variables. Could somebody show me an example of a script that allows to assing different values of kmin kmax rmin and rmax for different data sets? Stanislav

3 2

A question about the new Artemis version
by Stanislav Stoupin 31 Mar '04

31 Mar '04

Hello all I just upgraded to the newest horae-031 package It looks to me that the new Artemis version (0.7.001) doesn't have that nice button "use previous background" anymore. If I am not mistaken the button allowed to subtract background fitted previously. Am I? Is it somehow hidden in the new version? Thank you in advance Stanislav

3 4

parameters in Athena's output files
by Bruce Ravel 23 Mar '04

23 Mar '04

Hi folks, Recently two separate people requested that Athena write a summary of the various parameters into the header of the column output files for mu(E), chi(k), and so on. That's a great idea and the next version of Athena will do this. In the interim, I wanted to point out a feature of Athena that some of you may not be familiar with. At the bottom of the Edit menu is a submenu called "Write a report." A report is a summary either of all groups or of the marked groups. There are three different output formats, but I suspect that most people will prefer the Excel spreadsheet format. Rather than explain it further, I'll leave you to give it go. The .xls file that gets written should be readable by any version of Excel as well as OpenOffice, Gnumeric, and Kspread. HTH B P.S. The final option in the "Edit->Write a report" menu is a peculiar output file that is of interest to folks who use Athena to process their data but who prefer XFit to Artemis for the analysis. -- 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/

1 0

uncertainties
by mauro＠rulp.org 23 Mar '04

23 Mar '04

Maybe this is a "newbie" question, but I have noticed that in artemis's new version after the uncertainties there are values in round parentesis. What they mean? Thanks, Mauro.

1 1

Confirmation
by jawad shah 23 Mar '04

23 Mar '04

Dear Sir, Is i am registered on your web side. With best regards Jawad __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

1 0

Re: Athena Suggestions
by Bruce Ravel 22 Mar '04

22 Mar '04

Dave, I hope you do not mind that I am answering via the mailing list. The answer I have planned will be something that I think others will find useful. On Saturday 20 March 2004 03:30 pm, Barton, David (DG) wrote: > LOCATION OF Eo > -Attached is two Ga XAFS spectra in an Athena file project. Look > closely at the chosen Eo positions, I think you would agree that the > choice is not near the maximum of the first derivative. These data > sets both have a fairly reasonable signal/noise so that shouldn't be > the source of the error. > > Athena Report of Eo: > --Ga_035 (10372.6 eV) and Ga_32-8 (10374.1 eV) > ==Eo difference = 1.5 eV > Using another plotting program: > --Ga_035 (10373.3 eV) and Ga_32-8 (10373.5 eV) > ==Eo difference = 0.2 eV > > I understand that using the maximum in the first derivative is just > an approximation of the Fermi Energy so the absolute value may not > be so meaningful. However, we often use relative changes in the > position of Eo as an indication of structural changes in our > catalytic materials, so it would be helpful if Ifeffit was slightly > more robust and precise in choosing the Eo value. Maybe you could > consider incorporating a "smoothing" parameter which would help > reduce the noise in the first derivative or some other algorithm > which makes a better choice in the presence of some noise in the > data. For the sake of everyone else, I'll mention that the data Dave sent me had a slightly ambiguous e0 because the peaks in the first derivative were split into two peaks about the same height and about 1/2 volt apart. In one case, Ifeffit's algorithm for identifying the peak came up with a point a bit to the left of the two peaks and the other time a bit to the right. In neither case did Ifeffit (and hence Athena) pick one of the points at the peak. These choices to the left and right of the peaks result in the unphysically large energy separation that Dave is asking about. My initial response to questions like this is that it is rarely wise to blindly trust a program -- ours or anyone else's -- to do the right thing all the time. Just because we get one spectrum right or someone else gets another spectrum right is not sufficient reason to always trust any program. If you need it to be right, check and make sure it is right. That was fine advice -- possibly even tautological. But it wasn't very practical. The software really should work hard to get it right as often as possible. You suggest smoothing. That would probably work pretty well in this case. Indeed, it woul probably result in choosing a value between the two peaks. That's closer to correct and would probably at least be more reproducible between spectra than what happened with your data. But it would not be a panacea. Look at Zr 0+ some time. The maximum in the first derivative is more than 10 volts above the Fermi energy. Smoothing would not fix the "maximum in the first derivative" algorithm in that situation. So even with a more robust algorithm, you would be well served to be sceptical. I think the solution to your problem is to be a bit more hands-on and to make use of more of Athena's features. I typically use Athena's preprocessing features to handle ensembles of related data. The details of what you might do vary from situation to situation, but here is the outline: 1. Import one scan. This is going to be your "standard" against which the rest will be compared, so it should be a trustworthy one. Calibrate it by hand using the Calibration option in the Data menu. Play around with the background removal and FT parameters until you are reasonably happy with the data processing. 2. Use the "Open many files" option in the Files menu to import several more of the data files in that ensemble of related data files. 3. When the column selection dialog comes up, make sure that the columns are properly selected. Before hitting the OK button, hit the button that says "Set preprocessing parameters". This will expand the column selection dialog, showing a new menu and bunch of checkbuttons. 4. From the menu labeled "Standard" select the first data file that you read in. This will activate all the checkbuttons below. Now select the buttons for "Align to the standard" and "Set parameters to the standard". 5. Now click the OK button. As each data file is imported, it will be aligned and the parameters, including e0, the background parameters, and the FT parameters, will all be set to the values you settled on for the first data set. Magic!! If all went well, then each data set will be calibrated the same way as the first one and the background and FT parameters will be well set. The caveat is that the automated alignment does not always work well. A quick plot will let you know if it failed and you need to go back and align by hand. But with data that is low noise and similar, it tends to work ok. Depending on your data set and what you are aiming to do, you may need to do some variation of what I described above. Of course, a change in Ifeffit's algorithm might still be in order. But, in any case, I encourage you to resolve your e0 problems by explicitly examining one data file and using preprocessing to make the rest consistent with the first. HTH, 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 2

Re: [Ifeffit] beeps?
by SCalvin100＠aol.com 18 Mar '04

18 Mar '04

It beeps for me on Windows XP, although it's pretty subtle (more a burp than a beep). --Scott Calvin Sarah Lawrence College

2 1

beeps?
by Peter Southon 18 Mar '04

18 Mar '04

>When this happens, is anything written to the screen? Does Artemis beep and >tell you to look at the ARTEMIS.TRAP file? If either is the case, I will >need to see what they say. Bruce, did you say Artemis beeps on errors? It doesn't seem to do that on my WinXP machine. I know its a simple thing (I have a simple mind), but it would be a great prompt to look at artemis.trap. Is there a sound problem with porting to Windows? Cheers, Peter Peter Southon Post Doctoral Fellow School of Chemistry University of Sydney NSW 2006, Australia +61 2 9351 4425

3 2