Re: Ifeffit Digest, Vol 5, Issue 4
In regard to global fitting, there are much better algorithms than a simple grid search, something we stared with the 70's. More recently I have had some good results with a very simple genetic algorithm called "differential evolution" by storn and price. It seems to be faster than simulated annealing, and it has the advantage of being very robust. It behaves well with hard constraints (e.g. integer programming) included by penalty functions (or if you like, terms incorporating a priori knowledge, from a bayesian point of view). It also looks to me like it would be trivial to parallelize for using multiple processors. I think the easiest thing to implement in feffit however would be simply to do a series of minimizations with (say, 1000) random starting points in the parameter space. This would just entail wrapping the minimization in a loop, and adding a way to summarize the results. Minimizations starting at differentpoints may end up in the same or different "attractors". If those corresponded to bad fits, throw them out. If they are adequate fits, keep them. Quite possibly more than one attractor could fit the data adequately. A cluster analysis of the results should indicate whether different solutions are equivalent (belong to the same attractor) or not. I don't think this should be very hard to do. Of course it easy to suggest that other people do the work, so I've been playing with these approaches myself using mathematica as my sandbox. The minimization code in feffit would have to be robust enough that it would give up gracefully (not crash) if it became numerically unstable. I think it should be fast enough that a global solution could be obtained in a couple of hours on a modern machine. If not, it could be done in an intrinsically parallel way on multiple machines. thanks - grant On Tue, 8 Jul 2003 ifeffit-request@millenia.cars.aps.anl.gov wrote:
Send Ifeffit mailing list submissions to ifeffit@millenia.cars.aps.anl.gov
To subscribe or unsubscribe via the World Wide Web, visit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit or, via email, send a message with subject or body 'help' to ifeffit-request@millenia.cars.aps.anl.gov
You can reach the person managing the list at ifeffit-owner@millenia.cars.aps.anl.gov
When replying, please edit your Subject line so it is more specific than "Re: Contents of Ifeffit digest..."
Today's Topics:
1. Re: ARE: [Ifeffit] Re: Ifeffit Digest, Vol 5, Issue 1 (Bruce Ravel) 2. Re: Estimating error in XAS (Scott Calvin) 3. Re: Re: Estimating error in XAS (Matt Newville) 4. Re: Estimating error in XAS (Scott Calvin) 5. Scanning of "Potential Surfaces" in EXAFS (Norbert Weiher) 6. Re: Scanning of "Potential Surfaces" in EXAFS (Bruce Ravel)
----------------------------------------------------------------------
Message: 1 Date: Mon, 7 Jul 2003 13:11:08 -0400 From: Bruce Ravel
Subject: Re: ARE: [Ifeffit] Re: Ifeffit Digest, Vol 5, Issue 1 To: XAFS Analysis using Ifeffit Message-ID: <200307071311.08259.ravel@phys.washington.edu> Content-Type: text/plain; charset="iso-8859-1" On Monday 07 July 2003 12:45 pm, Matt Newville wrote:
Anyway, I think using the 'epsilon_k' that chi_noise() estimates as the noise in chi(k) is a fine way to do a weighted averages of data. It's not perfect, but neither is anything else.
Exactly right! As Matt explained, there are reasons to believe that the measurement uncertainty is dominated by things that Parsival's theorem doesn't address and that measuring those problems is hard.
As Matt said, weighting by 1/chi_noise() is OK. As Scott said, weighting uniformly is OK. Those are two choices are the most OK I can think of, so Athena will let you choose between them.
While I am of the chorus of people agreeing with Grant that mu is not equal to <If>/<I0>, I can see no reason why Athena should actively prevent the user from looking at <If> or <I0>, if that is what he wants to do. The *current* version of Athena prevents this, but that's a bug not a feature! ;-)
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, 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/
------------------------------
Message: 2 Date: Mon, 7 Jul 2003 13:15:45 -0400 From: Scott Calvin
Subject: [Ifeffit] Re: Estimating error in XAS To: XAFS Analysis using Ifeffit Message-ID: Content-Type: text/plain; charset="us-ascii" In the anecdotal category, I've seen some fairly bizarre high-r behavior on beamline X23B at the NSLS, which I tentatively attribute to feedback problems. That line, as many of you know, can be a little pathological at times. I've also collected some data to examine this issue on X11A, a more conventional beamline, but have never gotten around to looking at it--I hope to soon.
In any case, I don't really understand the logic of averaging scans based on some estimate of the noise. For that to be appropriate, you'd have to believe there was some systematic difference in the noise between scans. What's causing that difference, if they're collected on the same beamline on the same sample? (Or did I misunderstand Michel's comment--was he talking about averaging data from different beamlines or something?) If there is no systematic changes during data collection, then the noise level should be the same, and any attempt to weight by some proxy for the actual noise will actually decrease the statistical content of the averaged data by overweighting some scans (i. e. random fluctuations in the quantity being used to estimate the uncertainty will cause some scans to dominate the average more heavily, which is not ideal if the actual noise level is the same). If, on the other hand, there is a systematic difference between subsequent scans, it is fairly unlikely to be "white," and thus will not be addressed by this scheme anyway. Perhaps one of you can give me examples where this kind of variation in data quality is found.
So right now I don't see the benefit to this method. Particularly if it's automated, I hesitate to add hidden complexity to my data reduction without a clear rationale for it.
--Scott Calvin Naval Research Lab Code 6344
Matt Newville wrote:
I'd assumed that vibrations would actually cause fairly white noise, though feedback mechanisms could skew towards high frequency. Other effects (temperature/pressure/flow fluctuations in ion chamber gases and optics) might skew toward low-frequency noises. I have not seen many studies of vibrations, feedback mechanism, or other beamline-specific effects on data quality, and none discussing the spectral weight of the beamline-specific noise.
On the other hand, all data interpolation schemes do some smoothing, which suppresses high frequency components. And it usually appears that the high-frequency estimate of the noise from chi_noise() or Feffit gives an estimate that is significantly *low*.
Anyway, I think using the 'epsilon_k' that chi_noise() estimates as the noise in chi(k) is a fine way to do a weighted averages of data. It's not perfect, but neither is anything else.
--Matt
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Grant Bunker says:
I think the easiest thing to implement in feffit however would be simply to do a series of minimizations with (say, 1000) random starting points in the parameter space. This would just entail wrapping the minimization in a loop, and adding a way to summarize the results.
Minimizations starting at differentpoints may end up in the same or different "attractors". If those corresponded to bad fits, throw them out. If they are adequate fits, keep them. Quite possibly more than one attractor could fit the data adequately. A cluster analysis of the results should indicate whether different solutions are equivalent (belong to the same attractor) or not.
I think there are at least two different (albeit related) purposes for "scanning potential surfaces" with IFEFFIT. One is to identify the candidates for good fits. This is not just a matter of improving the fitting routines so that there is a greater probability of finding the true global minimum; as most of us know quite well, the statistically best fit is not necessarily the one that corresponds most closely to physical reality. Grant's suggestion sounds like a really good way of identifying candidates for "good" fits, and thus reducing the possibility that a good solution is being overlooked. A second purpose for looking at the potential surface is to help the researcher better understand the relationships between the variables being fit. (Better than just a single correlation number, for example.) This may be helpful early in the fitting process, perhaps when a good model has not yet been found. It may also be useful for presentation of results to a skeptical audience! For these purposes, Bruce's plan to allow scanning over two variables while fitting the rest sounds very useful. --Scott Calvin Sarah Lawrence College
Dear Friends, thanks first for the many ideas you suggested. I must admit that I like all of them. When looking for a global minimum, the variant with some random starting points is for sure a good way of doing the job. With this one can also get a first impression, how many "attractors" can be found in the given system. The "systematic" scan on the other hand is really a good way of better understanding the correlation between the different parameters. So I will try to play around with both ideas. Bruce: thanks for the tip with the ifeffit script output - I'll use it for sure :) Have a nice day, Norbert On Tuesday 08 July 2003 20:07, Scott Calvin wrote:
Grant Bunker says:
I think the easiest thing to implement in feffit however would be simply to do a series of minimizations with (say, 1000) random starting points in the parameter space. This would just entail wrapping the minimization in a loop, and adding a way to summarize the results.
Minimizations starting at differentpoints may end up in the same or different "attractors". If those corresponded to bad fits, throw them out. If they are adequate fits, keep them. Quite possibly more than one attractor could fit the data adequately. A cluster analysis of the results should indicate whether different solutions are equivalent (belong to the same attractor) or not.
I think there are at least two different (albeit related) purposes for "scanning potential surfaces" with IFEFFIT. One is to identify the candidates for good fits. This is not just a matter of improving the fitting routines so that there is a greater probability of finding the true global minimum; as most of us know quite well, the statistically best fit is not necessarily the one that corresponds most closely to physical reality. Grant's suggestion sounds like a really good way of identifying candidates for "good" fits, and thus reducing the possibility that a good solution is being overlooked.
A second purpose for looking at the potential surface is to help the researcher better understand the relationships between the variables being fit. (Better than just a single correlation number, for example.) This may be helpful early in the fitting process, perhaps when a good model has not yet been found. It may also be useful for presentation of results to a skeptical audience! For these purposes, Bruce's plan to allow scanning over two variables while fitting the rest sounds very useful.
--Scott Calvin Sarah Lawrence College _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
-- Dr. rer. nat. Norbert Weiher (norbertweiher@yahoo.de) Laboratory for Technical Chemistry - ETH Hönggerberg HCI E 117 - 8093 Zürich - Phone: +41 1 63 3 48 32
On Tuesday 08 July 2003 02:02 pm, Grant Bunker wrote:
I think the easiest thing to implement in feffit however would be simply to do a series of minimizations with (say, 1000) random starting points in the parameter space. This would just entail wrapping the minimization in a loop, and adding a way to summarize the results.
Minimizations starting at differentpoints may end up in the same or different "attractors". If those corresponded to bad fits, throw them out. If they are adequate fits, keep them. Quite possibly more than one attractor could fit the data adequately. A cluster analysis of the results should indicate whether different solutions are equivalent (belong to the same attractor) or not.
If Norbert or anyone else is interested in playing around with what Grant suggests (or even one of the admitedly less-clever raster schemes that I suggested), I have a suggestion. One thing that Artemis will do for you is to write a script of ifeffit commands for doing a fit using the data and feff calculation currently imported. See the second item in the Edit menu. This script can be saved to a file and used as the basis for, say, a perl or python script to do any of the explorations of parameter space that have been discussed today. Here are some excellent notes from Matt explaining how to call ifeffit from perl, python, or C: http://cars9.uchicago.edu/ifeffit/refman/node106.html This is exactly what Sam and I do in our programs. And please do report back to this list. We'd love to know what you find! 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, 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/
participants (4)
-
Bruce Ravel
-
Grant Bunker
-
Norbert Weiher
-
Scott Calvin