[Ifeffit] the use of constraints

[Bruce Ravel]

On Friday 28 May 2010 12:01:25 pm Kellie Aldi wrote:
> I like better the idea of penalizing a fit when percap is outside of a
> defined range and thus "encouraging" the fit to settle percap somewhere
> inside this range. But in trying to use the restraint idea, including the
> fix suggested by Matt Newville for only penalizing the fit outside of the
> min/max range, percap still goes slightly above 1 (about 1.02) and in my
> results I get a value for the "penalty" that I am unsure how to interpret.
> Can this value be used to understand why the restraint still allows the
> value of percap to be outside of the defined "ideal" range?
> 

Hi Kellie,

There are two ways of bounding a parameter in Ifeffit.

 1. These math expression will provide a hard-walled boundary:

       guess a = 1
       def   b = max( 1.2, min(0.8, a) )

    If you then use "b" as a parameter in some other math expression,
    "a" will float as part of the fit.  "b" will take the value of "a"
    as long as it is in between 0.8 and 1.2.  If "a" floats outside of
    that range, then the value of "b" is limited.

    This certainly works to put a boundary on the value of "b", but it
    has a serious downside.  If "a" floats out of range, Ifeffit can
    no longer evaluate uncertainties.  This is because changing the
    value of "a" from 1.25 to 1.3 results in no change in the fitting
    model.  This the covarience matrix cannot be evaluated.

    So, what we need is a way to encourage "a" to stay with its
    boundaries, but in a gentler way.

 2. Try this instead:

       guess a     = 1
       set   scale = 100
       def   b     = scale * penalty(a, 0.8, 1.2)

    later on, tell Ifeffit to use "b" as a restraint. I don't know how
    this is done in SixPack, but in Artemis you simply flag "b" as a
    restraint.  In Ifeffit itself, you add the "restraint" argument to
    the argument list of the feffit() command.

    You then use "a" in subsequent math expressions rather "b" as in
    the previous example.

    This allows "a" to float outside the boundaries, but with a cost.
    As long as "a" remains within its boundaries, no problem.  If "a"
    floats outside its boundaries, the value of "b" is added in
    quadrature to the evaluation of chi-square, the fitting metric
    that is minimized in the fit.  The penalty function evaluates to 0
    when the first argument is between the values of the second and
    third arguments.  When it is outside that range, penalty evaluates
    to difference between the first argument and the value of the
    offended argument (i.e. a=0.7 evaluates to 0.1, as does a=1.3).

    If a fit really wants "a" to be outside the range, it can, but it
    has to minimize chi-square with the penalty added in quadrature.
    This, then nudges "a" into  the range that you think is
    reasonable.

    There are three mystery parameters: the upper and lower bounds and
    the value of "scale".  It is hard to come up with a fast rule for
    any of them.  Presumably, you have a sense of what the boundaries
    should be and are willing to argue for why you would choose them.
    "scale" is important in that it sets the "strength" of the
    penalty.  If scale is too small compared to chi-square, "a" will
    be too free to wander away from the boundaries.  If "scale" is to
    big, the penalty begins to behave like the hard-wall math
    expression from the other example.

    So, what is the right value of "scale"?  Hmmm... tough question.
    In my experience, the square root of reduced chi-square evaluated
    without the restraint is a good starting place.  That is usually
    big enough to make the restraint important without making it
    dominate the fit.

    As for the value of the penalty -- it doesn't have much inherent
    meaning.  It depends on the size of the scaling parameter.  Ditto
    for the extent to which the real variable drifts outside the
    range. 

As a more general comment, when a parameter is trying to be something
that you think it shouldn't be, you should look upon that as an
opportunity rather than a problem.  It is probably telling you that
one or more of your assumptions about your fitting model is poorly
cosidered.  What you usually need isn't another fancy trick of the
fitting software -- what you need is to make sure that you processed
the data correctly, implemented the mathematics of the fitting model
correctly, ran Feff correctly, and didn't make any other silly
mistakes while using a ridiculously complex and user-hostile program
like Artemis or SixPack!

Hope that helps,
B

-- 

 Bruce Ravel  ------------------------------------ bravel at bnl.gov

 National Institute of Standards and Technology
 Synchrotron Methods Group at NSLS --- Beamlines U7A, X24A, X23A2
 Building 535A
 Upton NY, 11973

 My homepage:    http://xafs.org/BruceRavel
 EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/