[Ifeffit] CFAVERAGE card in FEFF9

Matt Newville newville at cars.uchicago.edu
Mon Aug 13 13:47:13 CDT 2012


Hi Matthew,
On Aug 13, 2012 10:53 AM, "Matthew Marcus" <mamarcus at lbl.gov> wrote:
>
> I'm trying to simulate EXAFS on a nanoparticle of hydrogen-terminated
TiO2, whose atomic coordinates were given to me by a theorist.  For that, I
need to average over all Ti atoms, which seems to me is what the CFAVERAGE
card is for.  I tried using that per the attached feff.inp file with Jfeff
and it doesn't work in the following ways:
> 1.      If I define Ti as ipot 0, then FEFF complains that there is more
than one absorbing atom.  Isn't that the point of CFAVERAGE?
> 2.      If I don't do that, and I enter the edit window of jfeff, I find
that jfeff takes it upon itself to change my ipot statements so that Ti is
0, without changing the listing in the ATOMS cards.  This is clearly wrong,
so I change it back and hit File->Save.
> 3.      Once I get past all that it runs, but I don't get any xmu.dat or
other file usable by the plot tool.
> 4.      It runs so quickly that it's obvious it's just computing the
EXAFS from one atom, and I don't even know which atom it is, or whether
it's even a Ti atom.
>
> It's true that the manual states that CFAVERAGE is "unreliable".  I
suppose that's correct in the sense that "not working at all" counts as
"unreliable".
>
> Am I doing something stupid?  Is there a way to do what I want to do
without having to write a scripting program to do it manually?  Does
CFAVERAGE work better (at all) under earlier versions of FEFF?  I was
hoping not to have to develop software to perform a task which others have
already done.
>         mam

I can't speak for JFeff  -- haven't tried it yet -- but CFAVERAGE was
definitely "unreliable-at-best" in earlier incarnations of Feff8.  I think
the most obvious expectation (that Feff would go through all atoms of the
specified Z as the central atom, build a huge list of Paths, each weighted
by 1/Ntotal, where Ntotal is the number of central atoms in the cluster) is
not what is implemented.  For me, the coordination numbers always come out
as integers, which can't be right in general.

It's been a while since I've tried this, though so perhaps it is fixed.
Then again, your experience sounds like it might not be.

--Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20120813/93b1407d/attachment.html>


More information about the Ifeffit mailing list