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@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/