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

new tarbell, again
by Bruce Ravel 28 Apr '05

28 Apr '05

The 051 release is up on my website and on SourceForge. Carlo, Paul, Stefano, and Matt helped iron out all the problems in Athena and horae_update. Thanks guys! B -- Bruce Ravel ----------------------------------- bravel(a)anl.gov -or- ravel(a)phys.washington.edu Environmental Research Division, Building 203, Room E-165 Argonne National Laboratory phone and voice mail: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/

2 1

new release of Athena, Artemis, and Hephaestus
by Bruce Ravel 27 Apr '05

27 Apr '05

Hi folks! After a rather long hiatus, I have finally released a new source code tarball for my codes. You can grab it from SourceForge or from my web site. The linux, unix, and Max OSX users can run the horae_update script at any time. If history is any guide, Carlo will have new debian packages on SourceForge lickedysplit ;-) I plan to build new Windows executables on Monday morning. Hopefully there will be a Windows updater package soon after that. The list of new features, improvements, and bug fixes is quite long. Here is a summary of the most important new developments: Athena: ** You can now rebin your data using Ifeffit's rebin() function. Rebinning can be done on the fly in the column selection dialog as the data is imported or you can use the rebinning dialog which is found under the Data menu to rebin data already imported into Athena. ** After editing a parameter in one of the little text entry boxes, you can hit "enter" or "return" and the data will be replotted. This is a keyboard shortcut for the red plot buttons. ** There are several cosmetic changes on the main page intended to convey more information about the state of a data group. The large blue text in each section on the main page changes its shade of blue depending on whether the group is "up to date" with respect to that group of parameters. This will make sense when you see it! Artemis: ** This is almost certainly the last release for which there will be distinct stable and development versions of Artemis. Very soon I will be retiring the 0.7 branch of Artemis and renumbering the development branch as Artemis 0.8. For now the "artemis" program still refers to Artemis 0.7 and the "diana" program still refers to the development version. Soon, there will be no "diana" and "artemis" will refer to version 0.8. Here is a short PDF document with lots of pictures describing the major changes between 0.7 and 0.8: http://leonardo.phys.washington.edu/~ravel/misc/artemis0.8.pdf Hephaestus: ** I added a fluorescence line finder which works almost exactly like the current edge finder. I hope everyone enjoys the latest versions. I encourage everyone to try out the development version of Artemis. Have fun! Bruce -- Bruce Ravel ----------------------------------- bravel(a)anl.gov -or- ravel(a)phys.washington.edu Environmental Research Division, Building 203, Room E-165 Argonne National Laboratory phone and voice mail: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/

4 5

this time for sure!
by Bruce Ravel 26 Apr '05

26 Apr '05

Hi! I just uploaded release 050 of the source code tarball for Athena, Artemis, and Hephaestus to SourceForge and my web site. This version fixes some problems related to perl/Tk 804 that surfaced after the previous release two days ago. I think that this version should work well. I'm keeping my fingers crossed! Unfortunately, the horae_updater script that you linux and Mac users have on your computers will not work due to some changes at SourceForge. Grrrr! You can grab an updated version of the updater here: http://leonardo.phys.washington.edu/~ravel/software/packages/horae_update That version should work around the new changes at SF. I built and tested the codes on Windows today. I am using a new system for building Windows executables. Athena and Artemis worked fine, but there was a problem with Hephaestus. Hopefully I'll get that problem solved and a new Windows updater will become available soon. I'm really excited about this release -- Athena has seen lots of improvements and the development version of Artemis is almost ready for widespread use -- so I am eager to get over these hurdles. Regards, B -- Bruce Ravel ----------------------------------- bravel(a)anl.gov -or- ravel(a)phys.washington.edu Environmental Research Division, Building 203, Room E-165 Argonne National Laboratory phone and voice mail: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/

1 0

an interesting Atoms problem
by Bruce Ravel 22 Apr '05

22 Apr '05

Hi! This week I received an interesting question about Atoms whose answer will, I think, be of wide interest to the denizens of this list. The fellow who started the discussion had an atoms.inp file for ammonium tetraoxorhenate, (NH4)ReO4. Here is the input data: space = I 41/a a = 5.995 c = 12.440 rmax=10 core = Re1 atoms # elem. x y z tag Re 0.00000 0.00000 0.00000 Re1 O 0.20450 0.37860 0.17020 O1 N 0.00000 0.00000 0.50000 N1 These data ran atoms to completion, but then Feff stopped after issuing the statement about computing the "muffin tin radii and interstitial parameters" with this error message: WARNING: NO ATOMS CLOSE ENOUGH TO OVERLAP ATOM 10, UNIQUE POT 3!! My correspondant found this message a little cryptic and asked for advice. You will notice that the input data for atoms did not specify the hydrogen positions. Often it is fine with both Atoms and Feff to neglect the positions of the hydrogen atoms. For example, in a mineral phase with water molecules in the crystal structure, one can often just specify the positions of the water oxygens and neglect the water hydrogens. Doing so will still let both Atoms and Feff run to completion and leave you with a Feff calculation that is quite useful in analysis. So what happened here? Apparently my correspondent presumed that ammonium is like water in that specifying the locations of the hydrogens is not essential to the Feff calculation. Like in water, the hydrogens are fairly tightly bound to the nitrogen -- less than an Angstrom away -- so it might be ok. In this case, however, the hydrogens are essential. Adding the hydrogen position H 0.37200 0.45600 0.03300 H1 avoids the problem during the Feff run. Feff finishes and the analysis can proceed. It turns out that, while the N and the H are, indeed, quite close together, the N is quite a long way away from its next nearest neighbor, which is oxygen. The oxygen shell is split into two subshells, the closer of which is at about 2.85 Angstroms from the N. When Feff goes to compute the muffin tin potential, a near neighbor separation of 2.85 Angstroms is too large and it is unable to determine the radii of the atoms. That is the meaning of Feff's slightly cryptic error message. With the intervening hydrogen atoms, Feff's algorithm for constructing the muffin tins is no longer ill-defined -- the separation between atoms is no longer too large. To conclude, while it is probably unlikely that the hydrogen locations can be well measured by the EXAFS experiment, it is quite important to include the hydrogens in the theory. The rule of thumb that says that hydrogens in hydrated crystal structures can be neglected is not a very good general rule. This is certainly a case where the hydrogens cannot be ignored. Well, *I* thought it was interesting. Hopefully you did too! B -- Bruce Ravel ----------------------------------- bravel(a)anl.gov -or- ravel(a)phys.washington.edu Environmental Research Division, Building 203, Room E-165 Argonne National Laboratory phone: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/

1 0

RE: [Ifeffit] Estimation of Pt and Au particle size
by Barton, David (DG) 19 Apr '05

19 Apr '05

Scott: Thank you for your detailed and prompt response. I look forward to testing out your example file of fitting Pt particle size, it should be a good starting point to begin this type of "rough" analysis. After working though this "rough" analysis we will then consider if our data quality will allow for a more detailed analysis of particle shape or distribution. Where we want to eventually take this analysis is to determine if we can measure differences in the particle size distribution in a series of samples. Ifeffit Community: I am still open to additional example Artemis files, especially if someone has a file that they would want to share related to fitting Gold particle sizes. Regards, Dave > -----Original Message----- > From: ifeffit-bounces(a)millenia.cars.aps.anl.gov > [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf > Of Scott Calvin > Sent: Tuesday, April 19, 2005 9:29 AM > To: XAFS Analysis using Ifeffit > Subject: Re: [Ifeffit] Estimation of Pt and Au particle size > > > Hi David, > > Sure thing. I'll send you a Pt file as a separate email; I'll also > send you a copy of the paper we're currently preparing for > publication. The final versions we used we're big Ifeffit scripts > rather than Artemis files, but I'm sure I can scare up a > representative Artemis file from earlier in the process. > > Just a brief comparison of the two methods I've seen out there: > > 1) Fit the coordination number of each shell. Anatoly Frenkel has > several publication related to this. > > 2) Assume the crystallites are "roughly" spherical and constrain the > coordination numbers in a fit to reflect this. The only size-related > fitting parameter is then R, the radius of the crystallite. I have > written a few papers related to this method. > > Method 1 has the advantage that it can in principle handle any > morphology; Anatoly has used it with supported catalysts (they may > even have been Pt, but I don't recall offhand) and distinguished > between shapes like rafts, hemispheres, etc.. > > Method 2 has the advantage that is uses only 1 size-related > parameter. For a complicated fit or one with limited data quality, > that's nice. On the other hand, if the morphology is far from > spherical (e.g. needles), then it doesn't work very well. This method > can even be used with an empirical standard (as opposed to a > theoretical standard like FEFF) to give a (rough) model-independent > estimate of size. > > So I tend to think method 1 is better when you have a very uniform > sample, as can happen with supported catalysts, while method 2 is > often appropriate when you have a "messier" sample with roughly > spherical particles, as is often the case when wet chemical methods > are used. > > It should also be noted thatusing both techniques there have been > many reports that for polydispersed samples EXAFS yields a mean > smaller than that found by other methods (e.g. Scherrer analysis). > Part of that can be explained by the different weightings inherent in > the different techniques (EXAFS reads a 10 nm and 10 micron > crystallite as essentially identical, but "notices" a 1 nm > crystallite, while XRD would find the 10 micron signal dominant), but > I am not yet convinced that there isn't something else at work as > well. My group is currently planning a follow-up study of Pt to > resolve this question. > > --Scott Calvin > Sarah Lawrence College > > >Ifeffit Community: > > > >Over the past year or so I have seen several discussions of > >estimation of metal cluster size (collections of several to hundreds > >of metal atoms) using coordination numbers derived from EXAFS > >fitting. I was wondering if anyone on the list would be willing to > >share an example of their Artemis project file where this analysis > >was done successfully for Pt and/or Au particle sizes. As a first > >pass I am just interested in roughly estimating an average particle > >size with future considerations for estimations of particle size > >distributions if data quality and theory allows. > > > >Thanks in advance to anyone willing to share their project files. > >Given the number of experts in the field reading this list it just > >seemed to make sense to build upon the back giants. > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listi> nfo/ifeffit >

1 0

Estimation of Pt and Au particle size
by Barton, David (DG) 19 Apr '05

19 Apr '05

Ifeffit Community: Over the past year or so I have seen several discussions of estimation of metal cluster size (collections of several to hundreds of metal atoms) using coordination numbers derived from EXAFS fitting. I was wondering if anyone on the list would be willing to share an example of their Artemis project file where this analysis was done successfully for Pt and/or Au particle sizes. As a first pass I am just interested in roughly estimating an average particle size with future considerations for estimations of particle size distributions if data quality and theory allows. Thanks in advance to anyone willing to share their project files. Given the number of experts in the field reading this list it just seemed to make sense to build upon the back giants. Regards, Dave _________________________________ David Barton, PhD. The Dow Chemical Company Catalysis R&D 1776 Building Midland, MI 48674 USA

2 1

a basic (?) EXAFS question
by Juraj Majzlan 18 Apr '05

18 Apr '05

Hello, I have a question about fitting an EXAFS dataset. The compound is FeAs2, crystalline, and will be used as a model for further study. I was able to fit the first three shells very well. However, when I try to fit the fourth shell, I either get amplitude that is too high (> 2, with large errors), or 0.0. There are several single-scattering and several multiple-scattering paths in that region. Sometimes, only excluding one of the MS paths leads immediately from amplitude of >2 to 0.0. I'd appreciate any advise about what is the meaning of these changes and the inability to fix the spectrum. Attached are few pictures from Artemis. Thank you, Juro Majzlan ---------------------------------- Juraj Majzlan Institute of Mineralogy and Petrology Albert-Ludwig-University of Freiburg Albertstrasse 23b Freiburg, D-79104, Germany telephone +49-761-203-6416 fax +49-761-203-6407 http://www.minpet.uni-freiburg.de

3 3

RE: [Ifeffit] a basic (?) EXAFS question
by Kelly, Shelly D. 18 Apr '05

18 Apr '05

Hi Juro, Another thing to try, is to simply sum up all the paths from the crystal structure. Then compare the chi(k), and real and mag of the FT. Then plot the individual contriubtions from each of the paths to see how many are significant and how the different paths are contibuting to the overall model. If the model with all the paths is way different from the data then there may be a problem with the structure. SK ________________________________ From: ifeffit-bounces(a)millenia.cars.aps.anl.gov on behalf of Matt Newville Sent: Sun 4/17/2005 2:52 PM To: XAFS Analysis using Ifeffit Subject: Re: [Ifeffit] a basic (?) EXAFS question Hi Juro, I think you'd have to give us more information about how you did the fits. A few obvious questions are: what R range did you use for the fit? what was floated and what was fixed in the fit? how far out does the data go in k-space? I'm afraid that I don't know the crystallographic details of loellingite, but the EXAFS for many crystal structures get very complex by the fourth shell. This is especially true in slightly disordered structures where multiple-scattering and single paths nearly overlap. Part of the reason for this is that multiple-scattering paths can "spread out" in R-space, making it difficult to know where to stop including paths. --Matt On Sun, 17 Apr 2005, Juraj Majzlan wrote: > Hello, > > I have a question about fitting an EXAFS dataset. The > compound is FeAs2, crystalline, and will be used as a model > for further study. I was able to fit the first three shells > very well. However, when I try to fit the fourth shell, I > either get amplitude that is too high (> 2, with large > errors), or 0.0. There are several single-scattering and > several multiple-scattering paths in that region. > Sometimes, only excluding one of the MS paths leads > immediately from amplitude of >2 to 0.0. > > I'd appreciate any advise about what is the meaning of > these changes and the inability to fix the spectrum. > > Attached are few pictures from Artemis. > > Thank you, > > Juro Majzlan > > > ---------------------------------- > Juraj Majzlan > Institute of Mineralogy and Petrology > Albert-Ludwig-University of Freiburg > Albertstrasse 23b > Freiburg, D-79104, Germany > telephone +49-761-203-6416 > fax +49-761-203-6407 > http://www.minpet.uni-freiburg.de > _______________________________________________ Ifeffit mailing list Ifeffit(a)millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

1 0

Problems running Adobe Illustrator and IFFEFFIT package programs
by Matthew Ginder-Vogel 14 Apr '05

14 Apr '05

Hello, I was running Adobe Illustrator and then started up Hephaestus and Illustrator immediately crashed. For the sake of science I tried a couple other programs (sixpack and Athena) with similar results. Another person in my research group has also experienced these problems. I just wanted to alert other people to the perils of running Illustrator with one of the other programs. thanks, matt -- ******************************************** Matthew Ginder-Vogel Doctoral Student Department of Geological and Environmental Sciences Stanford University Soil and Environmental Biogeochemistry Group gindervm(a)pangea.stanford.edu ********************************************

1 0

Fwd: Re: Wrong window project file
by Scott Calvin 01 Apr '05

01 Apr '05

Thanks, Bruce. I'm moving this thread back to the ifeffit board: > >On Thursday 31 March 2005 18:41, you wrote: >> Incidentally, trying to shrink down the file has made me notice there's a >> lot of leftover stuff in the zip file--it looks like every data file I've >> ever used for chi data is still in there, as well as an old fit for each of >> those. Artemis almost never crashes any more (yay!), so those aren't a >> legacy of crashes--it just appears that every time I change data files it >> leaves the old one (and the associated fit) sitting in the project file. >> Since I sometimes use the same model with lots of different data, that >> starts to add up. > >Before I actually split Artemis into two branches, I was already starting to >think about the concept of maintaining a history of all fits done. The >presence of all that stuff makes no sense in the context of the stable >branch, but it is much more sensible in the development branch. > >The data should all be chi(k) data -- not so big and it compresses well. >Project files are big because the feff calc, not because of the data. The example I sent you had about 300 k of the zipped project file in old chi data, and the total file is 3 M, so yes, most of it in this case is FEFF calculations. I'm concerned, though, that the former number can only go up. Here's what I think is a reasonable hypothetical: someone has a really stable Artemis model that they like for their materials, and they use it over and over again on various samples. Unlike the file I sent you, it might also use a fairly small number of FEFF paths. Combine that with the fact that the time used by Autosaves is of course quite dependent on the size of the project file (and maybe the number of files in it? I'm not sure how the zipping algorithm works in that respect), and it becomes potentially annoying. I don't consider this a high priority issue, but it seems like something worth thinking about. >Another future reason for hanging onto all the data is batch functions. >Suppose you had a temperature series and wanted to fit each of the scans with >the same model. Wouldn't it be cool to tell artemis-of-tomorrow to fit all >the data and then show the temperature dependence of one of the sigma^2s? Yes, it would be very cool. I guess I'm just asking for a "clear history" option or something like that. In the mean time, I'm happy to do this manually if I know it won't confuse Artemis. If I just root around in the zipped project file and remove the old .chi and .fit files, will that confuse Artemis in any way? --Scott Calvin Sarah Lawrence College

2 1