Hi all, Happy New Year to all! I've been busy pushing the new versions of Artemis and Ifeffit pretty hard (3-edge fits, over 100 paths, also over 100 guess,def,set parameters) and they seem to be behaving pretty nicely. There are certainly some advantages and some disadvantages to this compared to the old FEFFIT package; one major advantage is this will certainly reduced the learning curve for new undergraduates in my group. I am posting now because I am not sure I understand the behavior of the spline clamps in Ifeffit. When I set a top end to the spline range that is below the top of the data range, the high spline clamp has very little, if any, effect. (As a simple example, if I take the "clamp.prj" project that comes with Athena and set all of the spline ranges to top out at 400 eV, all four backgrounds look the same.) Is this what should be happening, or is this a bug? In case this is a bug, here's the version information: Athena 0.8.024 and ifeffit 1.2.4 running on Windows XP. I'll also be glad to send a project file to Bruce or Matt if they wish, although it would just be the clamp.prj file with the top of the spline range changed... --Scott
On Tuesday 13 January 2004 03:41 pm, SCalvin100@aol.com wrote:
I am posting now because I am not sure I understand the behavior of the spline clamps in Ifeffit. When I set a top end to the spline range that is below the top of the data range, the high spline clamp has very little, if any, effect. (As a simple example, if I take the "clamp.prj" project that comes with Athena and set all of the spline ranges to top out at 400 eV, all four backgrounds look the same.) Is this what should be happening, or is this a bug?
I don't know if it's a bug or not. (And if you think it is, I'd encourage you to make a minimal ifeffit script, perhaps with lines culled from Athena's ifeffit buffer, and send that to Matt. I suspect a minimal script would be most useful to him. And if you use a data file that comes with Athena's examples, like the one you mention, then you can send the script alone.) It would also be useful to check if the different clamp values lead to data that looks the same when plotted but has small numerical differences or if it is numerically identical. It is possible that it is not a bug and is, instead behaving as advertised. The clamp is a penalty applied to the chi-square that is calculated in determining the spline. The penalty is computed using (by default) the last five data points in the data range. The more those five points in the spline deviate from the data, the bigger the penalty. Thus, the sense in which it is a clamp is that it tries to coerce the spline to settle down to the level of the data at the end of the data range. If the spline is such that, with no clamp, the spline intersects the data points at the end of the spline range, then applying the clamp will have little effect. If the spline doesn't "want" to diverge from the data in any case, then adding a penalty for doing so won't be much of a penalty at all. The clamp.prj demo project works as a demo because the splines *do* diverge from the data near the end of the data set when the clamp is set to 0. That the splines don't do so 400 volts above the edge is not necessarily indicative of a problem with the clamps. B -- Bruce Ravel ----------------------------------- ravel@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 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/
Hi Scott, The clamp uses the last data points, not the points near kmax (and similarly it uses the data points at above k=0, not k=kmin). I'm not sure if this is a bug (that is, it's not obvious what 'right' is here), but it's probably not the behavior you were hoping for ;). It's probably safe to assume that the clamps should persuade chi to be close to 0 at kmin and kmax (that is, this seems as safe as assuming chi should be near 0 at k=0 and k=last_data_point), so I don't see much reason to keep it like it is. I'll (try to) make the clamps use the points near kmax (and kmin) for 1.2.5 --Matt
participants (3)
-
Bruce Ravel
-
Matt Newville
-
SCalvin100@aol.com