Re: convolution with "corrections"

[Matt Newville <newville@cars.uchicago.edu>]

John, Alex, Gilles,

>   Gilles Hug asked about possible bugs with the CORRECTIONS Vr Vi card with
> FEFF, since he observes spurious behavior at the edge.
>
> > It seems that the convolution is adding a pre-peak which is an
> > artefact. A convolution by a gaussian with another program does not
> > give such peak. (It is less handy, however, because it is necessary
> > to convert to evenly spaced data, etc..).
> > Can anyone confirm if it is a bug, a incorrect use or an artefact of
> > te mathematics use by feff?
>
> Such spurious behavior is not a "bug" per se, but rather a limitation of the
> rough approximations used in the CORRECTIONS [it's not a pure convolution]
> which are only meant to allow small corrections (not more than a an eV or so)
> at the end of a calculation. Thus the card should only be used with caution,
> as noted in the FEFF Doc.  The more precise way to add edge shifts and
> broadening is with the EXCHANGE card, but this requires recalculating
> the phase shifts and redoing the EXAFS/XANES calculations with a different
> imaginary potential and edge shifts.
>
>    Alex tried, but could not reproduce the specific output Gilles reported,
> in particular the noticeable shift in the edge position with Vr = 0. There
> shouldn't have been any such shift.  Thus we will need the feff.inp file
> to probe this further. Indeed, it is important for all bug reports to include
> the version number of the FEFF code used together with the feff.inp file,
> so we can try to reproduce the bug.  Please see the FEFF Doc on Bug Reports.

The doc cautions that results are not as accurate as using
EXCHANGE, but the example shown uses VICORR = 1.0.  I don't
see a suggested upper limit.

I believe that Gilles may be right, or at the very least raise
a valid point:  spurious peaks can definitely arise from
convolving with non-evenly spaced data. I've seen this myself
in my own codes. I don't see that subroutines xscorr() or
conv() enforce an evenly spaced energy grid, but then I don't
fully understand what they're doing.  It all looks too clever
for me.  What is the "impure convolution" that is done?

Have you verified that Gilles' problem is _NOT_ due to a
poorly-done convolution? When I do a brute-force convolution
using Gilles' data interpolated onto an evenly-spaced grid, it
looks fine to me.  It sounds to me like Gilles' has the same
experience, and was simply complaining that doing the
interpolation and convolution by hand was a lot more work than
running feff.

I agree that putting in a correction to the EXCHANGE potential
is more exact, but for CORRECTIONS to mu_total in FF2XX, a
brute force convolution with a lorenztian, gaussian, or
pseudo-voight function might be the right thing.

--Matt

|= Matthew Newville        email: newville@cars.uchicago.edu
|= GSECARS, Bldg 434A      voice: (630) 252-0431
|= Argonne Natl Lab        fax:   (630) 252-0443
|= 9700 South Cass Ave     http://cars.uchicago.edu/~newville/
|= Argonne, IL 60439 USA