[Ifeffit] background subtractions

[Bruce Ravel]

Hey Carlo,

Here is my answer to your other two questions, also CCed to the
mailing list.

	
> 2. What is the justification for fitting the background during the 
fitting
> process.  I understand that it is important to remove background large k
> oscillations but it seems to me that this is better done without the bias
> of simultaneously fitting FEFF shells.  I know that Steve Wasserman and
> Jeff Terry have a Mathematica background subtraction algorithm which
> allows you to back FT the region below Rbkg and subtract it from chi.
> This seems to be roughly the same idea as the background fit but is less
> biased by the fitting.  I would appreciate your comments.  Also, is this
> now a part of FEFFIT or is it solely in Artemis?

It is roughly the same idea, but I would say that you *want* the
background to be biased by the fitting.

The issue here needs to be restated in terms of what is meant by "a
good background removal".  Implicit in the back transform algorithm
that you describe is the assumption that a good background removal
makes the low-R region "look pretty".  That is, one assumes that the
low-R regions should tail away in some monotonic fashion.  Basically,
this is an esthetic argument rather than a statistical or scientific
argument.  On some level, subtracting away a portion of the spectrum
via a back transform algorithm is not horribly different from
modifying the plot of the chi(R) spectrum with Photoshop or The Gimp.

First off, I should explain how the background co-refinement in
Ifeffit works.  You define a lower bound of the fitting range in
R-space.  This Rmin value takes the role of Rbkg in the autobk
algorithm.  That is, Rmin is the cutoff in R-space above which you
will use Fourier components from feffNNNN.dat files to fit the data
and below which you will use a spline to fit the data.  The spline is
determined in exactly the same way that the spline in autobk is
determined.

Is this cheating in terms of number of `independent' point?  No.  The
splin has exactly the number of knots corresponding to the band whose
width in R is from 0 to Rmin.  That is, different information is used
by the spline than by the rest of the fit.

Why is another pass of the autobkl algorithm needed at this stage?
Why couldn't autobk just do the job correctly up front?  Well, this is
sort of a numerical issue.  Autobk has a really hard job to perform.
If you Fourier transform the entire mu(E) spectrum, you will find that
the Fourier contribution from the mu0(E) function is much much huger
than the contribution from the chi(K) function.  Thus autobk is
attempting to isolate something small out of something large.  By the
time Artemis sees the data, mu0(E) is all gone.  Further refining the
background is thus a matter of separating something small from
something small.

The REAL REASON to do the background co-refinement is because Ifeffit
(and thus Artemis) will report on the **correlations between** the
background parameters and the things you are really interested in,
such as delta_R and sigma^2.  This is improtant.  Even more it is a
way of defining "goodness" of a background removal that removes esthetic
concerns.  A "well-removed" background is one that is not too highly
correlated with the fitting parameters.  Of course, "not to highly" is
a rather subjective, but it atleast is a number to work with.

So what is the right value of Rmin?  Well, you want to choose an Rmin
that is high enough to make a pretty picture (esthetics is not
entirely without merit, after all) but low enough so as not to
introduce excessive correlation with the fitting parameters.  Rmin,
therefore, is one of the parameters that you need to fiddle with in
your data.  For oxides (and carbides, nitrides, etc) Rmin might be
quite low.  Indeed, there may not be a value which gives a spline that
is loosely correlated with the fitting parameters and which also
satisfies the esthetic criteria of a pretty low-R region taht tails
off monotonically.  To avoid harming the data by excessive correlation
with the spline, you may be forced to accept low-R peaks even in your
published data.

Finally, how does this discussion relate to the background removal
done in Athena?  Well, it should be clear by now that you cannot know
the right value of Rmin a priori.  You have to do some fits and
measure the correlation between the background and the fitting
parameters to judge what Rmin should be.  Good practice with Athena is
to choose a rather low value of Rbkg and not worry that some icky
little low-R peaks might remain in the data.  If you choose a low
Rbkg in Athena, you can always choose a higher Rmin value in Artemis.
But you cannot go the other way.  You should not choose a value of
Rmin that is *lower* than the Rbkg used in Athena because then you
will not correctly evaluate the correlations.


> 3. When it comes time to report results, is it better to be able to
> subtract the background?  Is it legitimate to report fitting parameters
> without including the "hidden" background parameters?

I say yes, it is better to subtract the background found by Artemis.
(That's what the "use previous background" button does.)  Esthetics,
as I confessed above, is still important.  And yes, reporting fitting
parameters from a fit with a background co-refinement is most
certainly legitamate.  Indeed, it is more so because you can also
report the level of correlation with the background spline.  This
gives you reader MORE confidence in your results and a better ability
to interpret their validity.

Sorry I was so long winded, but these are subtle issues.  When I give
a series of lectures on data analysis, I usually spend about 30
minutes discussing background issues.

HTH
B

PS:  Background co-refinement is, like everything else mathematical,
something done by Ifeffit.  Ifeffit does all the heavy lifting,
Artemis just keeps it all organized.
	
-- 
 Bruce Ravel  ----------------------------------- ravel at phys.washington.edu
 Code 6134, Building 3, Room 222
 Naval Research Laboratory                          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/