Hi to all, I have noticed that Atoms fails to generate a correct "feff.inp" file in the case of alloys. For example, let's take the Ni_xCu_{1-x}, x=0.5, an fcc substitutional. If I put Ni as central atom and give 0.5 occupancy on the shared Cu-Ni site (0,0,0.5) the result is a normal Ni fcc without Cu. At the moment I modify my feff.inp by hand to simulate alloys, but maybe I'm just not using Atoms properly. If this is the case, it could be useful to insert your answer in the FAQ. Cheers, Mauro
Hi Mauro, Nope; you're using Atoms right. Atoms properly only simulates regular crystals (i.e. something with a space group), and a random alloy doesn't quite qualify. (If there was a regular pattern to the substitution, then there would be a superstructure, and you wouldn't need to give shared occupancy.) That doesn't mean, however, that we haven't found all sorts of ways of using Atoms to do non-crystallographic things. But yes, you do have to modify the feff.inp by hand to handle an alloy. I describe this procedure at: http://cars9.uchicago.edu/iffwiki/Doped?highlight=%28CategoryNotBulkCrystals... I will point out that in your case you actually don't have to worry too much; all you should have to midfy is the central (absorbing) atom. Why? Because copper and nickel scatter electrons in a very similar way, and EXAFS is generally not considered to be sensitive to the differences. Thus it's OK to model your alloy as all fcc Ni with a copper at the absorbing site for the Cu edge, and just plain fcc Ni for the Ni edge. Note that bond lengths, ss's, and E0's may differ, but you're presumably fitting those anyway...the feff paths themselves should be fine. --Scott Calvin Sarah Lawrence College
Hi to all,
I have noticed that Atoms fails to generate a correct "feff.inp" file in the case of alloys. For example, let's take the Ni_xCu_{1-x}, x=0.5, an fcc substitutional. If I put Ni as central atom and give 0.5 occupancy on the shared Cu-Ni site (0,0,0.5) the result is a normal Ni fcc without Cu.
At the moment I modify my feff.inp by hand to simulate alloys, but maybe I'm just not using Atoms properly. If this is the case, it could be useful to insert your answer in the FAQ.
You should modify feff.inp by hand. No automatic procedure generating a single cluster that will be characterized by statistical RDF of AB, AA and BB correlations exists and here is why. In any individual cluster the radial distribution of neighbors Rho_{AB}(r)= dN_{AB}/dr, where dN is the number of A-B bonds in interval dr, is not representative of an ensemble since the requirement that the number of B type neighbors to the A type atom in each "shell" is equal to the bulk concentration of B can be satisfied only for the central A atom (that has coordinates 0,0,0). There is an interesting procedure of simulating a random alloy cluster that was published by J. Moonen, J. Slot, L. Lefferts, D. Bazin, H. Dexpert in Physica B, 208 & 209 (1995) 689-690. They populate the cluster 5000 times, truly randomizing the "average" cluster, but each of their individual clusters has RDF deviating from the average. It is besides the point though that to simulate the EXAFS of an alloy it may not be important to generate such a statistically random cluster because the single scattering or multiple-scattering paths {A<->NN<-->NN<-->A) depend only on the types of neighbors in the linkages and not so much on the surrounding. It is due to the transferability of photoelectron amplitude and phase that makes it not too sensitive. Anatoly -----Original Message----- From: ifeffit-bounces@millenia.cars.aps.anl.gov [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of Mauro Rovezzi Sent: Sunday, November 13, 2005 5:19 PM To: IFEFFIT Subject: [Ifeffit] atoms and the alloys Hi to all, I have noticed that Atoms fails to generate a correct "feff.inp" file in the case of alloys. For example, let's take the Ni_xCu_{1-x}, x=0.5, an fcc substitutional. If I put Ni as central atom and give 0.5 occupancy on the shared Cu-Ni site (0,0,0.5) the result is a normal Ni fcc without Cu. At the moment I modify my feff.inp by hand to simulate alloys, but maybe I'm just not using Atoms properly. If this is the case, it could be useful to insert your answer in the FAQ. Cheers, Mauro _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Dear Mauro,
FEFF is very sensitive towards subtle changes in the atom list as caused by
introducing a vacancy or replacing a Ni by a Cu atom as you describe. Imagine
an FCC system with 50% atom A and 50% atom B. ATOMS has no a priori knowledge
how it should distribute A and B in the different shells. Unfortunately
each of
the possible combination will give you a slightly (or heavily) different XANES
signature.
ATOMS could use a random number generator to decide how a certain point
in space
should be occupied. In the above example it would give each atomic position in
the AB alloy a 50% chance to be either A or B. This will result in a
FEFF input
file corresponding to only one of many possible atomic permutations. This
particular atomic configuration might be close to reality - but it might as
well be unreasonable.
For this reason ATOMS does not include the occupancy in its calculations.
However, here's a workaround:
Use atoms to generate a feff.inp for pure A. Then use a script which randomly
replaces A with B with a probability suiting your needs (be sure to use a good
random number generator). In theory you need to calculate all possible
configurations of your cluster and do a FEFF run for each of them. I tried
something similar some time ago and found that the XANES pattern converges if
you do ~40 calculations of di
Hi Norbert, I'm comparing the answers we just gave. I have almost never used FEFF for XANES...would you agree that =EXAFS= is insensitive to the difference between Ni and Cu scatterers (except, of course, for the structural differences that can be handled by fitting parameters such as delr, ss, and e0)? --Scott Calvin Sarah Lawrence College
Dear Mauro,
FEFF is very sensitive towards subtle changes in the atom list as caused by introducing a vacancy or replacing a Ni by a Cu atom as you describe. Imagine an FCC system with 50% atom A and 50% atom B. ATOMS has no a priori knowledge how it should distribute A and B in the different shells. Unfortunately each of the possible combination will give you a slightly (or heavily) different XANES signature. ATOMS could use a random number generator to decide how a certain point in space should be occupied. In the above example it would give each atomic position in the AB alloy a 50% chance to be either A or B. This will result in a FEFF input file corresponding to only one of many possible atomic permutations. This particular atomic configuration might be close to reality - but it might as well be unreasonable.
Hi Scott,
would you agree that =EXAFS= is insensitive to the difference between Ni and Cu scatterers (except, of course, for the structural differences that can be handled by fitting parameters such as delr, ss, and e0)?
I was just doing the same comparison. I perfectly agree with you that Cu and Ni are indistinguishable in terms of the EXAFS backscattering contribution. For the XANES I would be more careful making such a statement - although I never tried out simulating an alloy consisting of neighboring atoms... Norbert
On Sunday 13 November 2005 16:19, Mauro Rovezzi wrote:
Hi to all,
I have noticed that Atoms fails to generate a correct "feff.inp" file in the case of alloys. For example, let's take the Ni_xCu_{1-x}, x=0.5, an fcc substitutional. If I put Ni as central atom and give 0.5 occupancy on the shared Cu-Ni site (0,0,0.5) the result is a normal Ni fcc without Cu.
The only thing Atoms "fails" to do in the case you describe is to mislead you into thinking that the problem is so simple as you would like it to be. http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2002-July/000092.html (The second link on that page does not get redirected properly at this time. Look on this page: http://cars9.uchicago.edu/~ravel/talks/course/notes.html ) Scott's and Anatoly's responses with suggestions for dealing with the dopant problem were chock full of excellent advice. B -- Bruce Ravel ----------------------------------- bravel@anl.gov -or- ravel@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://cars9.uchicago.edu/~ravel EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/
Hi all, Anyone out there have spectra for a NiO standard? I bet one of you does, since there was a request for a NiO atoms.inp file a few months ago. I have a referee who wants to see that our data that matches Ni metal very well doesn't also match NiO well (I'm presuming this referee is not someone too familiar with EXAFS!). So anyway, also let me know how you'd like me to credit the data (e.g. a footnote listing you and the beamline it was collected on). Thanks! --Scott Calvin Sarah Lawrence College P.S. And no, Matt's database doesn't have NiO, and yes, the Lytle database does...but the Lytle data is not thoroughly documented and so I avoid it when possible.
participants (6)
-
Anatoly Frenkel -
Bruce Ravel -
Mauro Rovezzi -
Norbert Weiher -
Scott Calvin -
Scott Calvin