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

Re: EXAFS analysis of homonuclear metal clusters
by m.bondin＠pgrad.unimelb.edu.au 02 Aug '04

02 Aug '04

Thanks Bruce, I will of course be honest and self critical of my findings in order to support my approach to modelling the data. I also thought I would place this on the list to see if anyone else had encountered, or seen examples re EXAFS analysis of such systems. Apologies about the double post - my email told me the first was not sent and then lost the draft. Cheers, Mark -- Mark Bondin PhD student School of Chemistry, University of Melbourne (03) 8344 7015 (Tower lab) 0409 252 983 (mobile)

1 0

EXAFS analysis of homonuclear metal clusters
by m.bondin＠pgrad.unimelb.edu.au 30 Jul '04

30 Jul '04

Dear mailing list - This is a general EXAFS question I decided to post in regards to your collective thoughts and/or experience with this EXAFS analysis approach. I am currently attempting to model a number of Fe-S clusters with nuclearities of 2, 3, 4, 5, and 6. In some cases (where all the Fe atoms are chemically equivalent i.e. same oxidation state and coordination geometry) it is easy to approach this by assuming a single Fe absorber model. When the Fe atoms become inequivalent (oxidation states which may be a mixture of I, II or III, and different coordination geometry) I can average the environments (by including all interactions and ajusting coordination numbers for the different iron atoms accordingly) again into a single Fe absorber model. The fits go well, giving realiable bond lengths (when compared to available crystallographic data), DW's, and statistics (I am also keeping in mind the number of refined parameters to ensure a well over-determined fit for each of the models). My only hesitation, and main reason I am posting this question, is that I am not completely sure this is a reasonable assumption as the Fe atoms are in different oxidation states and will have different E0's. What I do know is there is a shift of roughly 2 to 3 eV in E0 to higher energy for every increase, by one, in oxidation state (i.e. Fe(I) to Fe(II)). Is there any way of determining if this small difference in energy, and hence E0, between the Fe atoms in the clusters can or cannot be neglected in modelling the EXAFS? Regards, Mark -- Mark Bondin PhD student School of Chemistry, University of Melbourne (03) 8344 7015 (Tower lab) 0409 252 983 (mobile)

2 1

one more thing about atoms error
by Carlo U. Segre 30 Jul '04

30 Jul '04

Bruce: One more thing I noticed. If I try FEFF7 there is an error at the same spot, however, FEFF8 and FEFF8-exafs do work. 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 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre

2 2

EXAFS analysis of homonuclear metal clusters
by m.bondin＠pgrad.unimelb.edu.au 30 Jul '04

30 Jul '04

Dear mailing list, This question relates to an EXAFS analysis approach I am currently investigating in respect to a number of iron-sulfur clusters with nuclearities of 2, 3, 4, 5 and 6. The analysis is easy enough to perform when the Fe atoms in the clusters are chemically equivalent (i.e. same oxidation states and coordination environments) and can be simplified to a single Fe absorber model. The analysis gets a little tricky when the oxidation states of the Fe atoms, and also coordination environments are different hence the sites become chemically inequivalent. The approach that I use takes into account these different environments and resulting populations for each of the iron atoms, again collapsing into a single Fe absorber model and I am able to obtain nice fits of the data with bond distances in close agreement with compounds in which these distances have been obtained through crystallography. The DWs, visual fit and statistics are also well behaved and I have taken into consideration the number of refined parameters to ensure a well over-determined fit to the models (i.e. the data is not simply fitting to anything with lots of fitting variables). The main hesitation I have, and reason for me posting this question, is for the compounds in which the Fe atoms are in different oxidation states we would expect there to be differences in the E0 of these atoms. I know that for every increase, by one, in oxidation state (i.e. Fe(I) to Fe(II)) there is a shift in E0 to higher energy by roughly 2 to 3 eV (as can be observed in the XANES from studies conducted on mononuclear Fe compounds). I am really not sure as to what extent this effect may alter the EXAFS signal for a cluster. From what I observe in the fitting I would say not much, but I would like to know if this has been encountered, or thought about before by anyone else (i.e. maybe in reference to EXAFS studies on other homonuclear metal cluster systems in catalysis). Regards, Mark -- Mark Bondin PhD student School of Chemistry, University of Melbourne (03) 8344 7015 (Tower lab) 0409 252 983 (mobile)

1 0

problems with atoms and tkatoms
by Carlo U. Segre 29 Jul '04

29 Jul '04

Bruce: I have been trying to generate a feff input file with atoms and tkatoms. Here is what happens when I work within artemis I import an atoms.inp that I wrote out previously (attached). This file written out previously when I used it with tkatoms to make a *.xyz file. I notice that it does not properly read the angles but I fill them in anyway. When I run atoms to get the FEFF input file I get the following error: Tk::Error: Illegal division by zero at /usr/share/perl5/Xray/ATP.pm line 634. Xray::ATP::ATP_corrections at /usr/share/perl5/Xray/ATP.pm line 634 Xray::ATP::parse_atp at /usr/share/perl5/Xray/ATP.pm line 387 main::run_atoms at /usr/bin/artemis line 5565 [\&main::run_atoms] Tk callback for .frame3.canvas2.frame.notebook.atoms.frame2.button1 Tk::__ANON__ at /usr/lib/perl5/Tk.pm line 225 Tk::Button::butUp at /usr/lib/perl5/Tk/Button.pm line 111 (command bound to event) main::__ANON__('Tk::Error: Illegal division by zero at /usr/share/perl5/Xray/...') called at blib/lib/Tk.pm (autosplit into blib/lib/auto/Tk/Error.al) line 409 Tk::Error('MainWindow=HASH(0x96d864c)', 'Illegal division by zero at /usr/share/perl5/Xray/ATP.pm line...', 'Xray::ATP::ATP_corrections at /usr/share/perl5/Xray/ATP.pm li...', 'Xray::ATP::parse_atp at /usr/share/perl5/Xray/ATP.pm line 387', 'main::run_atoms at /usr/bin/artemis line 5565', '[\&main::run_atoms]', 'Tk callback for ..frame3.canvas2.frame.notebook.atoms.frame2.b...', 'Tk::__ANON__ at /usr/lib/perl5/Tk.pm line 225', 'Tk::Button::butUp at /usr/lib/perl5/Tk/Button.pm line 111', ...) 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 1792 If I run the same input file in tkatoms, I get a popup saying there is a divide by zero in ATP.pm line 634. If I try to generate an *.xyz file it works fine. I am using the latest version of horae. 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 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre

2 1

Importing in Athena
by Dave Baker 29 Jul '04

29 Jul '04

I have recently been looking at some standards and I came across some Cu foil data in a two-column .dat format; "energy" and "xmu". (Incidentally, it is standard data taken in '92 by none other than Bruce R. and Matt. N.) Anyway, the data seems to load just fine using either the "xmu.dat" or the "Mu(E)" import profile, and I can remove backgrounds, do both forward and backward FT's and generally manipulate the data normally. Everything is fine until I try to save the chi(k) data. The program displays that it's saving the file, but does not report success. The file is indeed written, but with a file size of zero. Following this attempt, the graph may or may not be stuck in the last plot, and if it is stuck, no amount of frantic clicking on my part changes it. The Ifeffit buffer is empty, and there are no error trap files. -Dave Baker ------------------------------------------------------------------------ -- 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 4

RE: [Ifeffit] artemis development in the near future
by SCHLEGEL Michel 177447 29 Jul '04

29 Jul '04

Bruce, > * Windows users who would like to be involved with the development > branch should consider installing ActiveState's perl distribution > on their computers as that would allow you to test the source code > as it becomes available. If anyone is interested in this, I can > help get you started. But I would encourage only the enthusiastic > to consider this. Most users will prefer to use the executables > that I will build for the stable version. Well, to paraphrase some recent declaration, sometimes you have Activestate, sometimes, you haven't, there's this little third category... Yes, I have installed ActiveState a long time ago, but that was just to run some script, and it is unclear to me if you plan to run the development versions of Athena and Artemis as script, or if you will ask each and every Windows user to compile his/her own little executable. In the later case, You'll have to explain me. Othervise, the new version runs fabulously great, apart from a minor point: I can't fit simultaneously several spectra (polarization data) in q-space. TApparently Artemis traps some kind of error message. but the software keeps on running. Otherwise, there's a little practical point which bothers me: when it comes to publishingand citing, we know how to shower praise on Matt, but we are still yearning for some sound reference for the Ravelware. Is there any chance that this 'bug' will get fixed in the near future? Best regards, Michel Schlegel

4 4

RE: [Ifeffit] artemis development in the near future
by SCHLEGEL Michel 177447 29 Jul '04

29 Jul '04

Bruce, > On Wednesday 28 July 2004 12:47 pm, SCHLEGEL Michel 177447 wrote: > > versions of Athena and Artemis as script, or if you will ask each and > > every Windows user to compile his/her own little executable. In the > > later case, You'll have to explain me. > > Well, the point I was trying to make was that building and testing > windows executables adds considerably to my work. I would like to be > able to release the development version frequently -- the > early-and-often approach to software development. If I have to build > windows exes everytime, that will slow me down, wear me out, and make > it not worth my time to bother with the whole idea of a fork. Yes, I now, we Windows user recriminate a lot, demand even more, and offer little in return.. ;-) > > Othervise, the new version runs fabulously great, apart from a minor point: > > I can't fit simultaneously several spectra (polarization data) in q-space. > > TApparently Artemis traps some kind of error message. but the software > > keeps on running. > > OK, thanks for the report. I'll look into it. q-space fitting is not > one of the well-tested corners of the code since I never do > that myself. I am aware of Matt's recommandation - that fitting in R-space should be preferred. However, there are sometimes informations in the q-space on the nature of backscatterers from, e.g., the shape of the amplitude enveloppe of the Fourier-filtered contribution. Plus, it is always interesting to compare fitting results in both spaces. I ran a test fit in q-space with four spectra and Artemis 0.7.008. It seems that the fitting stage is performed well, and the fitting results in the q-space are even displayed in the Graphics windows. Trouble seems to arise when Artemis tries to write the log file. The 'Artemis palettes' windows doesn't appear on the screen. I then tried to fit into R-space (worked well), and again into q-space: the same error message appeared. I copied the message displayed on the console into the attached file. Best regards, Michel Schlegel

2 1

RE: Ifeffit Digest, Vol 17, Issue 23
by yaelp 29 Jul '04

29 Jul '04

didnt get any instruction thanks yael >===== Original Message From ifeffit(a)millenia.cars.aps.anl.gov ===== >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: weights data processing (Bruce Ravel) > 2. Re: EXAFS question (Bruce Ravel) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 26 Jul 2004 09:06:13 -0400 >From: Bruce Ravel <ravel(a)phys.washington.edu> >Subject: Re: [Ifeffit] weights data processing >To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> >Message-ID: <200407260906.13553.ravel(a)phys.washington.edu> >Content-Type: text/plain; charset="iso-8859-1" > > >I wanted to add a coupe more comments on Stafano's questions regarding >k-weighting in Athena and Artemis. > >Regarding k-weights in Athena: Athena's default for the k-weight using >background removal is 1. I chose that pretty much for the reason that >Scott gave. Ifeffit's default is 0, so this is a situation where >Athena and Ifeffit have different default behavior. As for the >insensitivity of your data to this value, I would say that it is >situational. Sometimes, the k-weight can have a dramatic influence on >the background removal. Stability of the background removal and its >impact on subsequent analysis has been a frequent topic of discussion >in this forum. k-weight, then, is yet another parameter that can >impact the stability of your spline. > >Rgearding k-weights in Artemis: Scott and Matt covered the "why" of >k-weights. How k-weights are actually used by Artemis when fitting >and plotting is a bit complicated. See section 5.8.4 of the >(incomplete) artemis document for a detailed explanation of how >k-weighting is used in Artemis. > http://leonardo.phys.washington.edu/~ravel/software/exafs/doc/artemis.pdf > >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: 2 >Date: Mon, 26 Jul 2004 09:37:31 -0400 >From: Bruce Ravel <ravel(a)phys.washington.edu> >Subject: [Ifeffit] Re: EXAFS question >To: "Norman White" <gn-white(a)tamu.edu> >Cc: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> >Message-ID: <200407260937.31266.ravel(a)phys.washington.edu> >Content-Type: text/plain; charset="iso-8859-1" > >Norman, > >Your question is the sort of thing that is appropriate for the Ifeffit >mailing list, so I am CCing my answer there. You should consider >joining the mailing list. It is a great resource and gives you access >to a large number of experts who can answer your questions. > > >On Friday 23 July 2004 03:38 pm, Norman White wrote: >NW> In going through Matt Neville's xas_fun_slides.pdf file that was >NW> included with the Athena software, I noticed on slide 36: > > MN > The Fe-O distance in FeO is 2.14 � A, but the first peak is at 1.6 � A. > MN > This shift in the first peak is due to the phase-shift, > MN > delta(k): sin[2kR + delta(k)] . > MN > A shift of -0.5 � A is typical. > > >NW> I asked him in an e-mail about the shift and he said (edited): > > MN > For traditional XAFS analysis, we do a relatively simple Fourier > MN > transform. This simple FT would give a peak in chi(r) at 'R' if > MN > the oscillatory part was sin[2kR]. Since it's sin[2kR + delta(k)] > MN > instead, there's a shift. > MN > > MN > It turns out that, to first order, delta(k) is linear and has a > MN > negative slope of about 1: > MN > delta(k) ~= -k ~= -2k (0.5), > MN > > MN > so that the shift in phase is about 0.5A. > >NW> I asked if this was true for all elements and he said: > > MN > It's a typical value for most bonds, but shouldn't be taken as an > MN > accurate number (and it's easy enough to calculate). > >NW> >NW> How is an accurate shift calculated? Is this correction performed > >This calculation is computed quite accurately by Feff. Indeed, >getting that calculation (and the related calculation of the >scattering amplitude) correct is the raison d'etre of Feff. > >NW> automatically in Athena? If it is a constant, why is it not simply >NW> included in the step producing the radial distribution function from >NW> the k values? Can it be accurately calculated? The manual had >NW> statements that seemed to imply that it could be calculated with the >NW> Atoms program but did not explain how at a level I understood. >NW> >NW> Matt neville stated in an e-mail that: > MN > The phase shift correction can be made fairly easy with > MN > SixPack and with Artemis as well as Ifeffit. > >It's not a constant and treating it as such would be specious at best, >and it is not something that Athena intends to compute. However, >since it is something that Feff computes, one can imagine using the >results of Feff. How this is done is slightly different in Athena as >in Artemis. > >At the level of Athena, we know the absorbing atom but it is not >actually necessary to know what the material is to use Athena >effectively. In Artemis, on the other hand, we do have to know >something about what the materials is. This difference between the >two explains the rationale for how phase correction works i the two >programs. > >In Athena, only a central atom phase correction is supported. This is >enabled by clicking the button that says "phase correction" in the >forward trasform section of the mail window. With that button >clicked, the central atom phase shift is subtracted from the data >before the transform is made. When you plot chi(R), then, the >transform will be peaked a little bit to the right of where it was >peaked without that button clicked. > >Artemis does a somewhat better job of this. In Artemis, you can >select a path to use for pase correction. With a path selected, the >central *and* scattering atom phase shifts will be subtracted before >transforming. This is possible in Artemis because we have the fuill >information about the material and the full feff calculation at our >disposal. In Athena, in contrast, we only know about the absorber and >I have never implemented (and don't really intend to do so) a way of >reading in a feff path for the purpose of phase shifted transforms. > >NW> >NW> I could not find where it explained how to do this. > >Did you read any of the documentation? > >For Athena: >http://leonardo.phys.washington.edu/~ravel/software/exafs/doc/Athena/athena… isc.html > The document is also available within Athena via the Help menu. > >For Artemis: Section 5.8.5 of >http://leonardo.phys.washington.edu/~ravel/software/exafs/doc/artemis.pdf > > >NW> I am looking at As adsorption on Fe-Al oxides and other minerals >NW> I know what the central atom is As. >NW> I can also estimate the oxygen bondlengths and the As-cation distance from >NW> the "corrected" EXAFS pattern and the literature. Is it possible to >NW> simulate an EXAFs pattern? >NW> Is so, how? > >Yes. > >Have you read the Artemis manual? > >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/ > > > > >------------------------------ > >_______________________________________________ >Ifeffit mailing list >Ifeffit(a)millenia.cars.aps.anl.gov >http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > >End of Ifeffit Digest, Vol 17, Issue 23 >***************************************

1 0

athena 0.8.030, artemis 0.7.008, hephaestus 0.04
by Bruce Ravel 28 Jul '04

28 Jul '04

Hi folks, A new tarball of the source for Athena, Artemis, and Hephaestus is now available at SourceForge and at my website. Linux, unix, and Mac OSX users can grab it or use the horae_update script at their leisure. Windows users will have to wait just a bit longer. Matt and I have almost settled on the new Windows release. More details should follow later this week. There are only a few new features in the codes this time around. The bulk of the changes are various bug fixes which should address the majority of the problems reported in the last two months. In particular, Artemis should now be a lot more stable. As always, please report any new problems you find with the new versions or any old problems that I did not actually fix! Among the changes to the Artemis: 1. An autosave file is written at certain times so that you can recover work in the event of a crash. 2. Artemis now uses a native menubar. This means that the menus can be driven entirely from the keyboard using (on PC keyboards) the Alt key. 3. There are a couple of small changes in functionality on the GDS page. Now, if you click on a different variable while editing a variable, the first variable will be defined before the new one is displayed. 4. The General->workspace variable is no longer used. I apologize to those who used this feature, but it was the source of too many problems. 5. The writing of trap files has been disabled in this version, but the same information still gets written to the console and should be included by cut-n-paste in bug reports. In Hephaestus there is a new page which shows a chart of the electronic transitions associated with the various single-electron fluorescence lines. Athena just has a bunch of bug fixes. It does not yet use a native menu bar. (Next time for sure!) A final note about Artemis. There is no drag-n-drop functionality anywhere in the program. It is quite easy to trigger a bug when the GDS page is displayed if you click the mouse button and then drag the mouse to another part of the Artemis window. I do not know the cause of this bug, but it is easy to avoid. 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/

4 16