- 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

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

artemis development in the near future
by Bruce Ravel 28 Jul '04

28 Jul '04

Hi folks, As some of you may know, I have been planning for a while to fork Artemis into two branches -- stable and development. It's going to work something like this: * The current version (0.7.008) will be the stable version. (Yes, I am fully aware of the irony of calling any version of Artemis "stable". ;-) For the next couple of months the feature set of stable Artemis will not change. I will only be fixing bugs as they become known. This will be the version recommended for most users. * The current version will be the base of the development version. I will add new features to this branch. Hopefully there will be enough users of the development branch that these new features will be sufficiently exercised as I get them written. * At some point I will decide to freeze the development branch and shift it down to the stable branch. That way, new features will eventually become available to the users of the stable branch, but only after they have been tested for a while. Hopefully, that will avoid some of the troubles we have had since version 0.7.000. * I will promise to make windows executables for every release of the stable branch. I won't promise to do so for every release of the development branch. * I haven't quite decided how to deal with numbering, but the stable branch will continue incrementing the minor number. The development branch will either start at 0.8.000 or at 0.7.500. In either case, the horae_update script will be modified to update either branch. * 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. * I am not planning to fork any of my other programs. Specifically, I do not see a benefit to forking Athena. Finally, here is a partial list of features that are on the drawing board for the development branch: 1. Update the atoms page to use an interface modeled on the new GDS page. 2. Enhanced functionality of the feff interpretation page 3. Keep a history of all fits run. This will allow such things as over-plotting of different fits with the data, comparison of the log files from different fits, and so on. 4. Generation of math expressions for delta_R based on the crystal parameters used in atoms. 5. Import of CIF files. 6. Import of PDB files and conversion to feff.inp format. 7. A bunch of internal modifications that will not be user visible but will support some of the changes above and will need extensive testing. OK, that's all the news that's fit to print. I hope that people are downloading and trying out the new release. 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

horae 038 Debian packages
by Carlo U. Segre 28 Jul '04

28 Jul '04

The horae packages for Debian have been built and are at my apt repository. Cheers, 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

1 0

RE: [Ifeffit] artemis development in the near future
by Jensen, Mark P. 28 Jul '04

28 Jul '04

Michel is right Bruce! We need a Ravelware reference to cite. That is a major bug! ------------------------------ Mark P. Jensen Chemistry Division Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439-4831 USA 630-252-3670 630-252-7501 FAX mjensen(a)anl.gov > -----Original Message----- > From: SCHLEGEL Michel 177447 [mailto:schlegel@azurite.cea.fr] > Sent: Wednesday, July 28, 2004 10:48 AM > To: 'XAFS Analysis using Ifeffit' > Subject: RE: [Ifeffit] artemis development in the near future > > 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 > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >

2 1

Ifeffit 1.2.6 for Windows
by Matt Newville 27 Jul '04

27 Jul '04

To follow up on Bruce's announcement: The full installer for Windows is now ready and available from http://cars9.uchicago.edu/ifeffit/download.html The Windows installer includes Ifeffit 1.2.6, and the latest versions of SixPack (0.50) and Horae (that is, Athena 0.8.030, Artemis 0.7.008, Hephaestus 0.04, and TkAtoms 3.0beta9), and can be downloaded either from the cars.uchicago.edu server or from the sourceforge.net server. An update for Windows (update #10) is also available, though this update is relatively large (~12Mb: almost half the size of the installer itself!). For those of you who are using the programs regularly, it may be worth the effort to download the full installer. --Matt

1 0

RE: [Ifeffit] Re: Artemis Question
by Kelly, Shelly D. 27 Jul '04

27 Jul '04

Hi John, I have a couple of comments to add to Bruce's reply: Feff is truly amazing. You can take a crystal structure for a Metal-oxide and apply it to a hydrated metal atom in solution with great success. -You can also do other non-physical things to the feff list of atoms and apply it to a real problem. There are a couple of thing to keep in mind. 1) Feff needs to have a list of atoms that extends well beyond the paths that are actually used in the fit. Always pad the feff.inp file by at least an Angstrom. If you are using feff calculation for the first time. Pad the feff list by one angstrom and then by two angstroms and check that the paths that you are going to use are the same. You do not want to use paths from the edges of the cluster that you give to feff in the feff.inp file. -Hence you need to use a structure like a metal-oxide to model a hydrated metal. 2) If you think that you have some unique geometry, linear multiple scattering paths then you need to be more careful to get these paths correct in the feff.inp file since they will have unique scattering amplitudes. 3) If the actually distance for the path included in the fit is different from the starting distance as given by the feff list, then you need to re-run the feff calculation. If you are just playing around you can move the paths by 0.5 Angstroms to get an idea that the path will work. In the final published fit, I like to see the change in the path length much less than this. If you are looking at solutions a great place to start is with the metal and the metal-oxide. Shelly > -----Original Message----- > From: Bruce Ravel [mailto:ravel@phys.washington.edu] > Sent: Tuesday, July 20, 2004 5:40 PM > To: XAFS Analysis using Ifeffit > Cc: John Butler > Subject: [Ifeffit] Re: Artemis Question > > > On Sunday 18 July 2004 11:38 pm, John Butler wrote: > > Basically, the problem that I'm having is that the system > I'm working > > on is a solution (to start I'm trying to look at a solution of Zinc > > Sulfate and then look at data with other components we're > interested > > in). Unfortunately, the part of the manual dealing with solution > > analysis hasn't been written yet, and the people I know who > use EXAFS > > don't do anything with solutions. > > > > I was hoping that you could point me in the right direction > for how to > > proceed with the analysis (e.g. is there anywhere I'm > likely to find > > the FEFF files ... is there a 'standard' way to attack this kind of > > problem). Of course I assume you're a pretty busy guy and have > > neither the time nor inclination to give me a detailed step by step > > guide or anything ... I was just hoping you could point me in the > > right direction, give me a couple of tips, and/or show me where to > > look. > > John, > > As you can see, I have forwarded you question along with my > answer to the > Ifeffit mailing list. > > You are correct to assume that I'm a busy guy. This week > (like each of the > other weeks this month) I am at NSLS collecting some data and > helping our > users. Fortunately, the mailing list is a solution to the > "busy expert" > problem. Enough people read and respond to the mailing list > that someone > should be available to answer just about every question. > > I doubt, actually, that you problem is really so hard to get > started with.. > Lots of problems in XAFS do not fall into nice little pigeon > holes. One > knows how to deal with data on an iron foil because one knows > what the > structure of iron metal is. Most real research problems, > obviously enough, > are problems precisely because the structure is not perfectly > well known. > > In the case of a solvated complex, there is probably some > sort of analogue > which can be used as a starting place. Perhaps there is some similar > compound whose structure *is* known. Perhaps your solvated > complex has a > crystalline form that is similar, at least in the local > environment, to the > solvated form. In any case, find something that is similar > to your real > material. Run feff and compare to the data. Perhaps your > analogue structure > will be close to your data. In that case, you should be able > to parameterize > the feff calculation in such a way that you can begin to > understand the ways > in which your complex differs from your analogue. > > Perhaps the analogue structure is a very poor match for the > data. That in > itself is information, in that it tells you to go look for a > different > analogue. > > The common theme to what I have said here (and indeed to any > analysis problem) > is that you make some educated guesses as to what you real > sample looks like. > You test those guesses. If they seem to be leading you in the right > direction, super. If not, make new (and newly educated!) guesses. > > My other piece of advice would be to spend some time fitting > known spectra. > If you are new to XAFS, then you are learning two things at > the same time: > how to interpret XAFS data and how to use my and Matt's > screw-ball analysis > programs! I consider it a good idea to spend some time > fitting data for > which you know the answer so that you can learn how to use > the codes before > plunging into the harder but more interesting problem of your > own research. > > Good luck and join the mailing list, > B > > > -- > Bruce Ravel ----------------------------------- > ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 > 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/listi> nfo/ifeffit >

5 4

Re: EXAFS question
by Bruce Ravel 26 Jul '04

26 Jul '04

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… 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/

1 0

RE: [Ifeffit] Re: Artemis Question
by Kelly, Shelly D. 26 Jul '04

26 Jul '04

Hi Scott, Feff uses the placement of the atoms to determine the size of the muffin tin radius and the norman radius, which define where the atom is verse where the atom is not. If there are no neighboring atom then these radii become unphysically large and then the scattering amplitudes will not be accurate. -Copper is kinda special. Copper has 12 neighboring atoms, so the muffin tin radii are pretty well constrained even with one shell. If you run a feff calculation with all the Cu atoms in a cluster to 7 Angstroms the top of the feff0001.dat file shows the radii for the atoms and it looks something like this: For large cluster Rmax=7.0 Angstroms: #Copper, Kittel, ISSP Feff 7.02 # metal, fcc # Abs Z=29 Rmt= 1.305 Rnm= 1.454 K shell # Pot 1 Z=29 Rmt= 1.273 Rnm= 1.391 # Gam_ch=1.761E+00 H-L exch # Mu=-5.472E+00 kf=1.724E+00 Vint=-1.679E+01 Rs_int= 2.104 Now do it again for N=12 and Rmax=3.0 For small cluster Rmax=3.0 Angstroms, N=12 # Copper, Kittel, ISSP Feff 7.02 # metal, fcc # Abs Z=29 Rmt= 1.233 Rnm= 1.467 K shell # Pot 1 Z=29 Rmt= 1.282 Rnm= 1.570 # Gam_ch=1.761E+00 H-L exch # Mu=-4.594E+00 kf=1.474E+00 Vint=-1.287E+01 Rs_int= 2.461 And again for N=2 and Rmax =3.0 For small cluster Rmax=3.0 Angstroms, N=2 #Copper, Kittel, ISSP Feff 7.02 # metal, fcc # Abs Z=29 Rmt= 1.256 Rnm= 1.815 K shell # Pot 1 Z=29 Rmt= 1.296 Rnm= 1.872 # Gam_ch=1.761E+00 H-L exch # Mu=-3.892E+00 kf=1.204E+00 Vint=-9.411E+00 Rs_int= 3.013 You can see that the norman radius gets really big for the last case, 1.391 to 1.570 to 1.872 and as a result the scattering amplitude changes. I show a comparison of the chi(k)xk for each of these inputs with a N=1.0, DE=0, SS=0, S02=1.0, DR=0 in the attached clustersize.jpg file. Shelly > -----Original Message----- > From: Scott Calvin [mailto:SCalvin@slc.edu] > Sent: Wednesday, July 21, 2004 9:53 AM > To: XAFS Analysis using Ifeffit > Subject: RE: [Ifeffit] Re: Artemis Question > > > Shelly said: > > > > >Feff is truly amazing. > > Amen! > > >1) Feff needs to have a list of atoms that extends well beyond the > >paths that are actually used in the fit. Always pad the feff.inp > >file by at least an Angstrom. If you are using feff calculation for > >the first time. Pad the feff list by one angstrom and then by two > >angstroms and check that the paths that you are going to use are the > >same. You do not want to use paths from the edges of the cluster > >that you give to feff in the feff.inp file. -Hence you need to use > >a structure like a metal-oxide to model a hydrated metal. > > Under what circumstances does FEFF actually need these extra atoms? > When I take the copper example included by Artemis, for example, I > can rerun the FEFF calculation with a cluster size of 3 angstroms, so > that FEFF only has the nearest-neighbors to deal with. The path > generated is identical to when a cluster size of 7 angstroms. > Certainly if someone is using FEFF8 with a self-consistent field > calculation it is necessary to have the cluster extend beyond the > furthers paths, but with FEFF6L is this true? > > (Incidentally, for the novices out there, I do NOT recommend being > satisfied with a single-shell fit when you have a reasonable guess as > to the structure beyond the first-shell. One reason can be seen > easily with Artemis: paths beyond the first-shell often have low-R > "tails" that contribute to the signal even at the first-shell peak. > Although the FEFF calculation for the first path may be the same > whether or not you also calculated paths further out, the Ifeffit fit > will be different depending on whether you include those "outer" > paths or not.) > > --Scott Calvin > Sarah Lawrence College > > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listi> nfo/ifeffit >

6 6

RE: [Ifeffit] weights data processing
by Kelly, Shelly D. 23 Jul '04

23 Jul '04

> -----Original Message----- > From: Stefano Ciurli [mailto:stefano.ciurli@unibo.it] > Sent: Friday, July 23, 2004 6:31 AM > To: ravel(a)phys.washington.edu; XAFS Analysis using Ifeffit > Subject: [Ifeffit] weights data processing > > > Hi folks, > > 1) when removing background using athena, there is an option of using > a k-weight different than 1 (I am NOT talking about k-weight for FT). > I noticed that changing this parameter the resulting chi(k) does not > change significantly. Actually, going from 1 to 4 as a value for > k-weight for Bkgd removal, the only effect I see is a significant > reduction of the peak below the first coordination shell in chi(R) > while the other features of the spectrum are essentially the same in > terms of absolute and relative intensity. A drastic change in both > chi(k) and chi(R) is seen if I use k-weight = 5 and above. What is > the exact meaning of it? I know what the meaning is in the FT > process, but I do not see the reason why I should use a weight > different than 1 (let's say 3 for my noisy data) for background > removal. How should I behave? Should I take the largest value of > k-weight so that the essential features of the chi(k) and chi(R) do > not change? Hi Stefano, I have found a procedure for removing the background that "almost" always works well. It goes something like this and uses different k-weightings in the background removal process. 1) Check out the curvature of the XANES region and how quickly the data goes from zero to 1, call this DExanes. There are in my small opinion two categories for each of these different parameters. Curvature of Xanes can be step like or it can have a large peak. DExanes can be small ~10eV for k-edges of Cu or wide ~30eV for L3-edge of U. 2) Choosing Ezero for the first time: If you have a wide DExanes, then choose Ezero up near the top of the edge. If you have a small DExanes, then choose Ezero around the middle of the edge. 3)Set kweight equal to one or zero (and no theory) and remove the background. This will emphasize the low k-region around the edge, but often get the background for the higher k-region not as well...especially for noisy data. 4)Check out the shape of the background function, the chi(k) data and the FT. Make sure that rbkg=1.0 is a reasonable thing to do. Make sure that you look at the chik data with all three k-weights. Often people say that there is no change in the chik data by changing the kwieght but they are looking at the chik*k3. The change will be greatest at low k, which you don't really see with chik*k3. 5) If you have a large peak in the XANES region, Athena may need help getting the bkg to go through that peak. You have two options. A) increase rbkg so that the spline has more freedom to curve in this region. or B) increase kmin of the spline range, essentially removing the large peak from the data. 6) Fit the first shell of your data, use a well padded chik data range...don't include at least one full oscillation at the beginning. i.e. use kmin=3 or greater. Monitor the value for ezero. If it is greater than 10eV you need to start over. (I have some more details on how to create a theory to be used for bkg removal on my web site http://www.mesg.anl.gov/Skelly.html from the 2004 NSLS EXAFS workshop presentation) 7) Read the theory back into Athena. Now Athena knows what the low k-range should look like, and you can increase the k-weight of the background, use kw=2 or 3, to get the high k-range part of the data correct as well. 8) Fit the data again and use as much of the k-range as possible. > > 2) In artemis, is it a bug or a wanted feature to have the > possibility to activate more than one button for k-weight for the fit > and FT? I suppose it is a wanted feature, but then I wonder what is > the meaning of using more than one weight for the fit and FT. I am > sure some of you can unveil this enigma. > Another couple of reasons to use more than 1 k-weight in the FT of the data: I have found that the uncertainties in the fitted values are about half as big by using all three k-weights, as opposed to using just one k=weight. I have also found that using all three k-weights will force you to model the data much more correctly. When you look at the fits, you need to look at the FT and the chi(k) data using all three k-weights. HTH Shelly

1 0

Re: [Ifeffit] Solution flow cells
by Scott Calvin 23 Jul '04

23 Jul '04

Thanks to all for the references, advice, etc.! This list really works wonders sometimes... --Scott Calvin Sarah Lawrence College

1 0

using atoms and feff
by Barton, David (DG) 23 Jul '04

23 Jul '04

I agree with Scott, the ICSD database of crystallographic structures has also been invaluable to my work on inorganic solids. However, the ICSD is truly an inorganic database in that it does not contain any compounds that contain carbon. For small molecule crystalline compounds that contain carbon the Cambridge Structural Database (http://www.ccdc.cam.ac.uk/ <http://www.ccdc.cam.ac.uk/> ) is quite useful. It contains ~300,000 crystal structures of organic and organometallic compounds. However, this database comes with a significant price tag, but if you can get access it is an amazing tool. Both of these crystallographic databases will write out the records in the CIF (Crystallographic Information File) format. I have written a command line Perl program which converts these CIF records to Atoms.inp files which can be used directly with Artemis. Shelly Kelly was kind enough to host the files: http://146.137.194.45/exafs.html <http://146.137.194.45/exafs.html> . Eventually, we may see a CIF import feature based on this code included in Artemis. Another Crystallographic File converter that I have found useful is CRYSCON (ShapeSoftware: http://www.shapesoftware.com/ <http://www.shapesoftware.com/> ). This shareware program will interconvert nearly all crystallographic file formats and, at my request, the author recently added support to export files with Ravel's ATOMS file format. Dave Barton The Dow Chemical Company, DND-CAT member at APS

1 0

RE: Ifeffit Digest, Vol 17, Issue 18: RE: Solution flow cells
by Wojciech Gawelda 23 Jul '04

23 Jul '04

Dear Scott, We have done some time-resolved XAFS measurements on aqueous solution of Ru(II)(bpy)3 complex using free-flowing jet. It forms a liquid sheet of approx. 100 microns thickness and thus you can avoid windows etc. However you might run into some trouble when using in vacuum. In principle you can find many manufacturers who provide these kinds of jets equipped with sapphire nozzles for dye lasers. I know that some of these jets are also used for cutting and polishing jewelry...if you need any more details you could look up our paper about the setup: M. Saes et al., Rev. Sci. Instrum., 75(2004), 24-30. I hope it helps, Wojciech Gawelda ********************************************************************* 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: vendredi, 23. juillet 2004 08:47 To: ifeffit(a)millenia.cars.aps.anl.gov Subject: Ifeffit Digest, Vol 17, Issue 18 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. Solution flow cells (Scott Calvin) 2. RE: Solution flow cells (Kelly, Shelly D.) 3. Re: Solution flow cells (Tsu-Chien Weng) 4. RE: Solution flow cells (Matt Newville) 5. RE: Solution flow cells (Jensen, Mark P.) 6. RE: Solution flow cells (SCHLEGEL Michel 177447) ---------------------------------------------------------------------- Message: 1 Date: Thu, 22 Jul 2004 15:34:00 -0400 From: Scott Calvin <scalvin(a)slc.edu> Subject: [Ifeffit] Solution flow cells To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <3.0.1.32.20040722153400.00b14170(a)mail.slc.edu> Content-Type: text/plain; charset="us-ascii" Hi all, I've been doing a literature search for an article I'm writing up, and I can't seem to find any examples of an XAS flow cell desgined for liquids. Sealed cells for liquids, yes; flow cells for passing gases over solids, yes; but no solution-chemistry flow cell. I feel like someone must have published work in that area before, but I can't seem to find it. So, does anyone know of any work done using a liquid-phase XAS flow cell? --Scott Calvin Sarah Lawrence College ------------------------------ Message: 2 Date: Thu, 22 Jul 2004 14:55:29 -0500 From: "Kelly, Shelly D." <SKelly(a)anl.gov> Subject: RE: [Ifeffit] Solution flow cells To: "XAFS Analysis using Ifeffit" <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <1C1577844A0BDF448E14E8CCB2F74424015A267F(a)ANLMAIL.anl.gov> Content-Type: text/plain; charset="us-ascii" Hi Scott, See below: > Hi all, > > I've been doing a literature search for an article I'm > writing up, and I can't seem to find any examples of an XAS > flow cell desgined for liquids. Sealed cells for liquids, > yes; flow cells for passing gases over solids, yes; but no > solution-chemistry flow cell. I feel like someone must have > published work in that area before, but I can't seem to find it. > > So, does anyone know of any work done using a liquid-phase > XAS flow cell? Simon Bare uses a flow cell for passing liquids/gasses over a sample. This one is a glass container with kapton windows with ports for input and output. Also I have seen something like that at PNC cat. I think that Ed Stern et. al. was using it. The one at PNC cat circulated the liquid through a boron carbide section that is x-ray transparent. Shelly ------------------------------ Message: 3 Date: Thu, 22 Jul 2004 16:44:40 -0400 From: Tsu-Chien Weng <tsuchien(a)umich.edu> Subject: Re: [Ifeffit] Solution flow cells To: Scott Calvin <scalvin(a)slc.edu>, XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <F452155A-DC1F-11D8-8255-000A959EB970(a)umich.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Hi Scott, > I've been doing a literature search for an article I'm writing up, and > I > can't seem to find any examples of an XAS flow cell desgined for > liquids. > Sealed cells for liquids, yes; flow cells for passing gases over > solids, > yes; but no solution-chemistry flow cell. I feel like someone must have > published work in that area before, but I can't seem to find it. > > So, does anyone know of any work done using a liquid-phase XAS flow > cell? We (Penner-Hahn group) have done solution EXAFS measurement and time-resolved XAS at Bio-CAT at the APS. A Kapton tube is used for x-ray window and connected to PE tubes using epoxy glue. Tsu-Chien <Chien>001000</Chien> ------------------------------ Message: 4 Date: Thu, 22 Jul 2004 15:55:07 -0500 (CDT) From: Matt Newville <newville(a)cars.uchicago.edu> Subject: RE: [Ifeffit] Solution flow cells To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <Pine.LNX.4.44.0407221538340.2941-100000(a)millenia.cars.aps.anl.gov> Content-Type: TEXT/PLAIN; charset=US-ASCII Just to follow up on and add to Shelly's and Tsu-Chien's responses: There's a paper by M. Hoffmann, et al (J. Fulton, and others from PNNL) on a flow-cell, especially for high pressure fluids. I believe it's in J Phys Chem (1999), but don't have the exact citation. This might be the one Shelly saw at PNC CAT. Mark Antonio has a nice electrochemical cell in which he can change both potential, but can't remember if he can flow in a changed solution... is that "flow"? I believe the catalyst people who run at ESRF (esp. the DXAFS line) have some nice flow cells too, but don't know if or where it's published. --Matt ------------------------------ Message: 5 Date: Thu, 22 Jul 2004 16:06:41 -0500 From: "Jensen, Mark P." <mjensen(a)anl.gov> Subject: RE: [Ifeffit] Solution flow cells To: "XAFS Analysis using Ifeffit" <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <0D4E53E4DC6CA449B9F71E5282984F8C2F0DE3(a)anchim2.chm.anl.gov> Content-Type: text/plain; charset="us-ascii" And just to add to Matt, Shelly, and Tsu-Chien's responses. Matt mentioned Mark Antonio's electrochemical cell. It is not a flow cell, though we did design a closely related, but unpublished, cell design for in the beam titrations. ------------------------------ Mark P. Jensen Chemistry Division Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439-4831 USA 630-252-3670 630-252-7501 FAX mjensen(a)anl.gov > -----Original Message----- > From: Newville, Matthew G. > Sent: Thursday, July 22, 2004 2:55 PM > To: XAFS Analysis using Ifeffit > Subject: RE: [Ifeffit] Solution flow cells > > Just to follow up on and add to Shelly's and Tsu-Chien's > responses: > > There's a paper by M. Hoffmann, et al (J. Fulton, and others > from PNNL) on a flow-cell, especially for high pressure fluids. > I believe it's in J Phys Chem (1999), but don't have the > exact citation. This might be the one Shelly saw at PNC CAT. > > Mark Antonio has a nice electrochemical cell in which he can > change both potential, but can't remember if he can flow in a > changed solution... is that "flow"? > > I believe the catalyst people who run at ESRF (esp. the DXAFS > line) have some nice flow cells too, but don't know if or > where it's published. > > --Matt > > > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > ------------------------------ Message: 6 Date: Fri, 23 Jul 2004 08:45:10 +0200 From: SCHLEGEL Michel 177447 <schlegel(a)azurite.cea.fr> Subject: RE: [Ifeffit] Solution flow cells To: "'XAFS Analysis using Ifeffit'" <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <3808A7D2DCEAD6118B63009027287265078A27(a)azurite.saclay.cea.fr> Content-Type: text/plain; charset="iso-8859-1" Scott, > I've been doing a literature search for an article I'm > writing up, and I can't seem to find any examples of an > XAS flow cell desgined for liquids. > Sealed cells for liquids, yes; flow cells for passing gases > over solids, yes; but no solution-chemistry flow cell. I > feel like someone must have published work in that area before, > but I can't seem to find it. Maybe not exactly a flow cell, but a rapid biblio research on "Web of Science" using the"stopped-flow" and "EXAFS or XAS or XANES" keywords has unearthed some 23 references over the last ten years, many of them probably utterly irrelevant. Nevertheless, I copied them in the attached text file. Best regards, Michel Schlegel

1 0

Re: Ifeffit Digest, Vol 17, Issue 18
by m.bondin＠pgrad.unimelb.edu.au 23 Jul '04

23 Jul '04

Hi Scott, I have read a paper in a recent issue from Journal of Synchrotron Radiation which may be of interest: J. Synchrotron Rad. (2004). 11, 204-208 [ DOI 10.1107/S0909049503028474 ] A versatile rapid-mixing and flow device for X-ray absorption spectroscopy K. Zhang, R. Liu, T. Irving and D. S. Auld Synopsis: A low-temperature rapid-mixing and flow system has been designed and implemented to monitor catalysis involving metal ions by X-ray absorption spectroscopy at the ID-18 beamline of the Advanced Photon Source. The results of the initial testing of the system are presented. The reseach in our group (Stephen Best) in Australia involves EXAFS of short-lived electrochemically generated solution species prepared via an "ex situ" continuous flow electrosynthesis cell (Australian Journal of Chemistry, Volume 54, page 705, 2001) - from what I understand though you are more interested in an "in situ" method as mentioned above. Cheers, Mark -- Mark Bondin PhD student School of Chemistry, University of Melbourne (03) 8344 7015 (Tower lab) 0409 252 983 (mobile)

1 0