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

Re: [Ifeffit] Measuring particle size of metal oxide
by Scott Calvin 28 Mar '10

28 Mar '10

Hi Bill, Sorry for my slow response; I've been swamped. And ironically, the fact that I'm very interested in your topic and wanted to give a good reply slowed me from getting to it! I'm also going to repost your question and my response to the IFEFFIT mailing list, as I think it's of general interest. I think you're missing a key idea concerning this procedure. Both my method and Anatoly Frenkel's method for finding particle size rely on comparing the effective coordination for different paths. I am skeptical of EXAFS determinations of particle size using only one path, as coordination number is hard to tease out from other effects that suppress amplitude (sample quality, disorder, vacancies...). But the relative coordination number of different shells is more reliable. So you should be using more than one path, each with its own r (the absorber-scatterer distance), in order to refine a single value for R, the crystallite radius. If you're using Artemis, this is simple enough to do, as each path has a reff value (which is r in the formula you give), and you can define a guessed parameter R. (To do this right, you need to make sure that the r for multiple-scattering paths is the distance from the absorber to the furthest scatterer, not the half-path length. That means putting the value in "by hand" for those paths, rather than using reff.) (If you want a really quick and dirty method, collect a reference for a bulk standard and for your sample, and multiply the FT of the bulk spectrum by the formula, adjusting R until you get a good match. The quick and dirty method doesn't handle multiple-scattering correctly, and has the usual problem of the fact that even for direct-scattering paths the peaks of the FT are shifted from actual absorber-scatterer distances. But it is model-free, which can be nice in some cases.) By the way, the formula you've cited is derived for spherical particles. If they're kinda sorta spherical, it will still give a decent approximation and fit. But if the particles are needle-shaped or flat plates, then it doesn't work well. You either have to derive another formula, or look at Anatoly's papers, which have addressed a number of common morphologies. So far, everything I've said applies to metals, and you asked about oxides. While most of this also applies to oxides, it's important to realize that the nearest-neighbor oxide paths are not suppressed at all; i.e. the formula doesn't apply until the first metal-metal path (but does apply to metal-oxide paths further out). This is because the surface of such particles is generally comprised of oxygen atoms, and the first scattering shell is thus fully populated no matter how small the particles are. --Scott Calvin Sarah Lawrence College On Mar 8, 2010, at 1:45 PM, bill.schwartz(a)yale.edu wrote: > Hi Scott, > > We met a couple of times at the EXAFS last two EXAFS workshops at > BNL, for relative beginners like me. > > I am attempting to determine the particle size of PdO particles > supported on Alumina (3% PdO/Al2O3). > > I am wondering if I can collect EXAFS data and use the formula in > your 2003 Journal of Applied Physics paper(*) to estimate PdO > particle size: > > N_nano = [1-3/4(r/R)+1/16(r/R)^3]N_bulk > > Here is a little more background: > > PdO particles on metal oxide supports are generally smaller and more > dispersed in comparison to Pd metal on the same support. Also, if > PdO is reduced and then re-oxidized at varying temperatures, the re- > oxidized PdO particle size varies with temperature, with higher > oxidation temperatures resulting in smaller PdO particle size. > > I have prepared a series of samples of 3% PdO/Al2O3, where the PdO > has been been reduced and then re-oxideized at various temperatures, > and I would like to use EXAFS to determine the coordination number > of my various samples. > > A major difference in my planned experiment compared to what you > described in your paper is that you examined nickel metal, while I > am looking at a metal oxide. > > So my current questions are: > > 1) Is the above formula reasonable for determining bulk particle > radius (R) of metal oxides? > > 2) If yes, then what is r, since scattering distance between Pd - > Pd and Pd - O are different? Is it reasonable to average the > distances? > > 3) Can N(nano) be determined by averaging the coordination numbers > for the Pd-Pd and Pd-O paths? > > Any guidance you can provide will be greatly appreciated. > > Sincerely, > > Bill > > (*) Determination of crystallite size in a magnetic nanocomposite > using extended x-ray absorption fine structure > > > > >

1 0

Anharmonic correction (Aaron Slowey)
by grant bunker 26 Mar '10

26 Mar '10

Aaron - There are a couple of things you should watch out for when fitting cumulants. First, you should make sure in the fitting process that the third cumulant C3 doesn't get much more than twice C2^(3/2) (i.e. 2 sigma^3) - values much larger than that are probably unphysical, even if they happen to give you a better fit. Second, the cumulant expansion loses its utility if it doesn't converge quickly enough. It's essentially an expansion in terms of order k*sigma, and if that approaches 1 the higher order cumulants may be large enough that convergence is questionable. If you are lucky and the effective distribution is Gaussian, or most of the variance is due to Gaussian broadening of a skewed distribution, it may converge OK, but that shouldn't be assumed a priori. Grant Bunker http://gbxafs.iit.edu

2 1

Anharmonic correction (Aaron Slowey)
by grant bunker 26 Mar '10

26 Mar '10

When fitting the third cumulant, you should watch out for a couple of things. First, you should make sure in the fitting process that the third cumulant C3 doesn't get much more than twice C2^(3/2) (i.e. 2 sigma^3) - values much larger than that are probably unphysical, even if they happen to give you a better fit. Second, the cumulant expansion loses its utility if it doesn't converge quickly enough. It's essentially an expansion in terms of order k*sigma, and if that approaches 1 the higher order cumulants may be large enough that convergence is questionable. If you are lucky and the effective distribution is Gaussian, or most of the variance is due to Gaussian broadening of a skewed distribution, it may converge OK, but that shouldn't be assumed a priori. Grant Bunker On Mar 26, 2010, at 1:41 PM, ifeffit-request(a)millenia.cars.aps.anl.gov wrote: > 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. Anharmonic correction (Aaron Slowey) > 2. Re: Anharmonic correction (Scott Calvin) > 3. Re: Anharmonic correction (Frenkel, Anatoly) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 26 Mar 2010 10:13:56 -0700 > From: Aaron Slowey <aslowey(a)usgs.gov> > To: ifeffit(a)millenia.cars.aps.anl.gov > Subject: [Ifeffit] Anharmonic correction > Message-ID: <9683660E-9ED8-4DBB-8E26-88586073B0F8(a)usgs.gov> > Content-Type: text/plain; charset="us-ascii" > > Dear XAFS community: > > I am fitting Hg L3-edge EXAFS of what I think are mercury sulfide nanoparticles. I fit Fourier filtered 1st shell Hg-to-Sulfur pair correlations for 5 spectra and obtain interatomic distances (r) that are 0.2 angstroms shorter than a cubic HgS(s) (i.e., metacinnabar) and Hg-to-S coordination numbers (N) that range from 2.6 to 3.0 (compared to N = 4 for metacinnabar). Delta_E0 values are less than a few eV, so I think the r's are not 'incorrect' as far as these preliminary fits are based on harmonic atomic vibrations/Gaussian pair-distribution functions. > > What intrigues me most about these data is that the fitted N's are consistent with the average 1st-shell Hg-S coordinations of 1 to 2 nm HgS clusters obtained by isotropically truncating the metacinnabar crystal lattice. In one case, I can also fit first-nearest Hg neighbors in the first shell, and this N is also consistent with a 1 nm HgS cluster. > > My objective is to scrutinize the tentative conclusion that the mercury sulfides in the samples consist of 1 to 2 nm subunits (within a larger aggregate, as determined by DLS). For instance, while the fitted N's are consistent with nanoclusters, the assumption of a metacinnabar lattice to estimate N of nanoclusters is undermined by the shorter interatomic distances fitted to the data. This got me reading the work of Manceau and Combes from the late 1980s and Frenkel et al. (2001) J. Phys. Chem. B. In Frenkel's paper (p. 12691), they describe that they used a "third cumulant" to account for anharmonic corrections, but I'm not sure how exactly this is implemented. > > It is something that you request in a feff.inp file, or is it a path parameter for IFEFFIT to include in its calculations? > > I am using Artemis on Mac OS X 10.6 (thanks to iXAFS 2.1.1 beta!!) to execute FEFF 7 calculations and fit my data. I noticed parameters called "3rd" and "4th" in the path dialog; is "3rd" the same parameter as, for example, the sigma_sub_i_superscript_(3) term in eqn (2) of Frenkel et al. (2001)? > > Thanks for reading this lengthy note... > > Aaron > > Branch of Regional Research, Water Resources > U.S. Geological Survey > Office (650) 329-5474 > Lab (650) 329-4069 > Fax (650) 329-4463 > 345 Middlefield Road, Mail Stop 466 > Menlo Park, California 94025 > http://profile.usgs.gov/aslowey > >

1 0

Anharmonic correction
by Aaron Slowey 26 Mar '10

26 Mar '10

Dear XAFS community: I am fitting Hg L3-edge EXAFS of what I think are mercury sulfide nanoparticles. I fit Fourier filtered 1st shell Hg-to-Sulfur pair correlations for 5 spectra and obtain interatomic distances (r) that are 0.2 angstroms shorter than a cubic HgS(s) (i.e., metacinnabar) and Hg-to-S coordination numbers (N) that range from 2.6 to 3.0 (compared to N = 4 for metacinnabar). Delta_E0 values are less than a few eV, so I think the r's are not 'incorrect' as far as these preliminary fits are based on harmonic atomic vibrations/Gaussian pair-distribution functions. What intrigues me most about these data is that the fitted N's are consistent with the average 1st-shell Hg-S coordinations of 1 to 2 nm HgS clusters obtained by isotropically truncating the metacinnabar crystal lattice. In one case, I can also fit first-nearest Hg neighbors in the first shell, and this N is also consistent with a 1 nm HgS cluster. My objective is to scrutinize the tentative conclusion that the mercury sulfides in the samples consist of 1 to 2 nm subunits (within a larger aggregate, as determined by DLS). For instance, while the fitted N's are consistent with nanoclusters, the assumption of a metacinnabar lattice to estimate N of nanoclusters is undermined by the shorter interatomic distances fitted to the data. This got me reading the work of Manceau and Combes from the late 1980s and Frenkel et al. (2001) J. Phys. Chem. B. In Frenkel's paper (p. 12691), they describe that they used a "third cumulant" to account for anharmonic corrections, but I'm not sure how exactly this is implemented. It is something that you request in a feff.inp file, or is it a path parameter for IFEFFIT to include in its calculations? I am using Artemis on Mac OS X 10.6 (thanks to iXAFS 2.1.1 beta!!) to execute FEFF 7 calculations and fit my data. I noticed parameters called "3rd" and "4th" in the path dialog; is "3rd" the same parameter as, for example, the sigma_sub_i_superscript_(3) term in eqn (2) of Frenkel et al. (2001)? Thanks for reading this lengthy note... Aaron Branch of Regional Research, Water Resources U.S. Geological Survey Office (650) 329-5474 Lab (650) 329-4069 Fax (650) 329-4463 345 Middlefield Road, Mail Stop 466 Menlo Park, California 94025 http://profile.usgs.gov/aslowey

3 2

Fwd: A problem Using FEFF8
by Bruce Ravel 25 Mar '10

25 Mar '10

Hi all, I am forwarding this email I received about a problem runninng Feff8. Does anyone have any advice for this fellow? B ---------- Forwarded Message ---------- Subject: A problem Using FEFF8 Date: Tuesday 23 March 2010 From: 裘南 <qiun(a)ihep.ac.cn> To: bravel(a)anl.gov Dear Mr. Bruce, My name is QIU Nan, I am a student from Institute of High Energy Physics, Chinese Academy of Science. I encountered a preblem When I calculated O K edge of cerium oxide(CeO2) using FEFF8. FEFF found bad counts: Occupation number in getorb is 4.000 , then FEFF repeated pteration again and again. The attached files are feff.inp I used and log1.dat that FEFF generated. Would you so kind to help me to finish this calculation? Best Wishes! QIU Nan 2010-03-24 ------------------------------------------------------- -- Bruce Ravel ----------------------------------- bravel(a)bnl.gov National Institute of Standards and Technology Synchrotron Measurements Group, Beamlines X23A2, X24A, U7A Building 535A, Room M7 Brookhaven National Laboratory Upton NY, 11973, USA My homepage: http://xafs.org/BruceRavel EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/

2 1

Re: [Ifeffit] A problem Using FEFF8
by Joshua Kas 25 Mar '10

25 Mar '10

Hi Qui Nan, There are several other parameters to the SCF card that may help. Try the following, * SCF rscf lscf niter ca nmix SCF 8.0 0 30 0.05 0 ca is the convergence factor in the Broyden algorithm. A lower value of ca will stabilize the SCF, but cause slower convergence. nmix is the number of iterations using the mixing algorithm before starting the Broyden algorithm. I have found that this is usually where the bad counts problem occurs, which is why I set it to 0. If this still doesn't work, try other values for the ca and nmix parameters. I have found that changing the ca and nmix parameters will usually (not always) fix the problem. Please email the list again if you continue to have problems. Cheers, Josh Kas > Dear Mr. Bruce, > My name is QIU Nan, I am a student from Institute of High Energy > Physics, Chinese Academy of Science. > I encountered a preblem When I calculated O K edge of cerium oxide(CeO2) > using FEFF8. FEFF found bad counts: Occupation number in getorb is 4.000 > , then FEFF repeated pteration again and again. The attached files are > feff.inp I used and log1.dat that FEFF generated. Would you so kind to help > me to finish this calculation? > Best Wishes! > QIU Nan > 2010-03-24 > > > > > ------------------------------------------------------- > -- > Bruce Ravel ----------------------------------- bravel(a)bnl.gov > > National Institute of Standards and Technology > Synchrotron Measurements Group, Beamlines X23A2, X24A, U7A > > Building 535A, Room M7 > Brookhaven National Laboratory > Upton NY, 11973, USA > > My homepage: http://xafs.org/BruceRavel > EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/ >

1 0

Is Athena NFS safe?
by David Ehle 23 Mar '10

23 Mar '10

Bruce, Is Athena NFS safe? i.e. If you have a user logged in on two different computers using a single NFS mounted home directory, are there any potential problems or conflicts when running Athena on both computers? Thanks! David.

2 1

Logicused in Artemis to do the error minimization
by Pralay K Santra 08 Mar '10

08 Mar '10

Dear All, After the final fitting in Artemis, we get the (i) total error; (ii) the final value of the parameters; (iii) the error in the parameters as well as (iv) the dependencies among the parameters. What is kind of logic used in Artemis to calculate these values? Is it Genetic optimization procedure used in this process? Can anyone help me by giving some references. I was going through the old posts and found two posts. One is this one: http://cars9.uchicago.edu/ifeffit/FAQ/FeffitModeling and the other one mentioned in the same. I am sorry to ask for some help which is not directly related to the XAFS. Thanks in advance. With regards, Pralay. --- Research Student. Solid State and Structural Chemistry Unit Indian Institute of Science Bangalore 560012 INDIA

4 4

iXAFS for Snow Leopard, aka 2.1 beta 1
by Ken McIvor 02 Mar '10

02 Mar '10

GOOD NEWS, EVERYONE ------------------- iXAFS 2.1 Beta 1 is now available for download: http://mrcat.iit.edu/ixafs/iXAFS%202.1.1%20b1.dmg It is a universal binary supporting Leopard and Snow Leopard. NO TIGER? --------- I don't know how to get one build to run on all three versions of OS X. I'd rather drop Tiger than further delay the beta. I FOUND A BUG ------------- Thanks for helping with the beta! Please email me directly instead of posting to the Ifeffit mailing list. OLD VERSIONS, EWW ----------------- I'm afraid so. The next release will update the bundled copies of Ifeffit and Horae. DIDN'T YOU SAY MARCH 1ST? ------------------------- Yes, I'm sorry for the delay. WHEN'S THE 2.2 RELEASE? ----------------------- Q2 2010. ;-)

1 0

Re: [Ifeffit] kind of solve the problem (can't save files)
by Michael Gaultois 27 Feb '10

27 Feb '10

Good afternoon Jaziel! If it involves security, permissions, protection and all that jazz, try right clicking on the executable (the Athena program) and then selecting "Run as Administrator." See if it works. Sometimes if it involves permissions issue this can be the case. Can you provide any further details about these libraries you speak of? Specific error messages are very helpful in helping diagnose the problem. If it's on a shared computer, the system administrator might have frozen the operating system drive *(i.e.* they don't want people changing anything, so they prevent you from writing things to the C:), which might explain why you can save to external devices. Warm regards, Mike -- Michael Gaultois 165 - 110 Science Place Department of Chemistry University of Saskatchewan Saskatoon, SK S7N 5C9 Canada Tel: (306) 966-8422 Fax: (306) 966-4730 "La patience est amère, mais son fruit est doux." Phaedrus "We are like butterflies who flutter for a day and think it's forever." Carl Sagan > Message: 1 > Date: Fri, 26 Feb 2010 17:32:06 -0700 > From: Jaziel Soto <jaziel7somu(a)gmail.com> > To: ifeffit(a)millenia.cars.aps.anl.gov > Subject: [Ifeffit] kind of solve the porblem... > Message-ID: > <d733687f1002261632n27063659o4daf76f61e9e682d(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi everyone (again), I kind of solve the problem. I can't save in C: but it > lets me save in external devices. I got some help and this person said the > problem might be something about security of vista and 7, something about > libraries (I don't know that much) the program uses that security doesn't > let me save on C: If someone has had a seemed problem have an idea of how > to > solve please comment... >

1 0