my response to some of John's comments re. the new feff_tables

[Bruce Ravel <ravel@phys.washington.edu>]

Hey John,

To respond to several of your points:

 jjr> Q: I wonder whether you have actually compared your tables with
 jjr> the old feff 3 tables?

Not yet.  On the TODO list.  One of the reasons for redoing the tables
is to address two limitations of the old tables.  (1) Limited edges
and elements.  (2) The old tables only had pure elements.  These
tables also only have pure elements for now, but one could imagine
including phase shifts and amplitudes for a variety of compounds as
well.  It would be handy to have, say, iron oxide tables for quick 'n'
dirty analysis of ferrite nano-particles.

 jjr> For ex, the old FEFF tables were made for 2 values of R for each
 jjr> element and interpolated in 1/R for a given nn pair in an effort
 jjr> to incorporate spherical wave effects.

Well, there are a ton of things that one could investigate.

I'd like to investigate how big a difference it makes to do a two
point interpolation relative to a single point.  In any case, the
little script I wrote is intended to be flexible.  It'll be easy
enough to modify the code to build two tabulations instead of just
one.

Similarly, it is easy to use any version of feff to generate the
tables -- something that Matt has already done.

Also, I anticipate that there are many problems in the tables that I
put on the web page.  Fine -- I suspect that some iteration will be
necessary.  Again, that's why you get the script along with the
tables. 

It would also be interesting to see if self-consistency has a
significant impact on the tables.  

Clearly, Matt and I need graduate students ;-)

 jjr> Also your choice of potentials is not clear to me. Do you use
 jjr> fcc potentials for all elements, or is that just the example?
 jjr> Or do you use the preferred xtalographic form of the solid for
 jjr> each element?

Actually I think it was bcc, but yes I used the same feff.inp for
every element, as I explain on the web page.  The tokens that begin
with % are substituted as-is with the appropriate data for each
calculation.  That is clearly non-physical, but it was easy to code up
in an afternoon without doing a few hours of research looking up the
crystal structures of non-obvious elements like fluorine and
praseodymium.

One thing I could do is make a data base of pure element crystal
structures and use code from atoms to generate the feff.inp files on
the fly.  That would be a good improvement, although it is not clear
to me that FCC copper is a better standard than BCC copper for the
copper in, say, YBCO.

 jjr> Also for the PC, do you anticipate subtracting 2 delta_c or the
 jjr> sum 2 delta_c + phi_feff?

I think that Matt answered this.  The tables just store the second
column of feff0001.dat.  The idea is that ifeffit will do "the right
thing" when someone asks for PC for, say, the Dy L2 edge.  In Athena,
I intend to just subtract the central atom part.  Athena is a data
processing program, not a data analysis program.  It is not
appropriate to expect the user to know even the species of the
backscattering atom at the level of Athena.

B

-- 
 Bruce Ravel  ----------------------------------- ravel@phys.washington.edu
 U.S. Naval Research Laboratory, Code 6134          phone: (1) 202 767 5947
 Washington DC 20375, USA                             fax: (1) 202 767 1697

 NRL Synchrotron Radiation Consortium (NRL-SRC)
 Beamlines X11a, X11b, X23b, X24c, U4b
 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/