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

Re: Ifeffit Digest, Vol 18, Issue 2
by m.bondin＠pgrad.unimelb.edu.au 03 Aug '04

03 Aug '04

Hi Shelly - thankyou for your detailed response - it helps greatly and is most appreciated. Cheers, Mark -- Mark Bondin PhD student School of Chemistry, University of Melbourne (03) 8344 7015 (Tower lab) 0409 252 983 (mobile)

1 0

info sought regarding file locking
by Bruce Ravel 03 Aug '04

03 Aug '04

Hi! In the recent release of Athena and Artemis, I believe I fixed the problem that Windows users were observing that files would get locked when in use by one of my programs. This would be a problem if, say, you imported a file into Athena and then wanted to rename or move that file using the file manager. I am interested to know if anyone is still experiencing any problems of this sort. If so, please describe to me in as much detail as possible what lead to a file getting locked by my program. I will assume that if I do not hear from anyone regarding this, that means that this is working properly. Thanks, 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] Re: EXAFS analysis of homonuclear metal clusters
by Kelly, Shelly D. 02 Aug '04

02 Aug '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 -- Hi Mark, I liked Bruce's response, but since you asked again. I will go out on a limb. I believe that your assumption is justified. The theoretical models built using Feff7 or less do not have different Ezero values based on the valence state of the absorbing atom. The difference is made by choosing a slightly different Ezero at the edge, rather than a difference in K=0 in the theoretical model. In addition, different Ezero's become important at low k-values. Using a kmin of 3.0 inverse angstrom or greater, I would not expect you to need different Ezero's. If you move kmin from something like 3.0 inverse angstroms to 1.5 inverse angstroms you might find that your model no longer works with one Ezero. Also, Ezero and Delr are correlated. So say you know delr then you might be able to "see" a few eV shift in Ezero, assuming that you are using a lot of low k in the data range. If you want to see the shift. Then I would get my hands on the metal oxides for each valence state. And then simultaneously fit each oxidation state together with the mixture...You might be able to pull the info out this way. -As Bruce suggested. It is unlikely that your data range and fit range will support more than one Ezero. To verify that only one Ezero is needed: Try several models with a each shell having it's own Ezero, or two Ezeros or one Ezero. Compare the reduced chi square values of the different models. If the reduced chi square value decreases by a factor of two or more then your data will supports more than one Ezero. Also check the uncertainty in the values for Ezero. If the values overlap considering the error then these Ezero-values are the same and should be only one variable instead of two. I am sure that you can find EXAFS papers of mixed Fe(II)/Fe(III) oxides such as magnetite, Fe2O3. I would guess that they are modeled with a single Ezero. HTH Shelly

1 0

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

01 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 29 Jul '04

29 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 29 Jul '04

29 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