October 2002 - Ifeffit - millenia.cars.aps.anl.gov

SUIs
by Bruce Ravel 22 Oct '02

22 Oct '02

Matt said: MN> Bruce also points out (again, correctly) that we have very little MN> experience training monkeys. OK. You caught me in a little, white lie. Perhaps it is possible to train a monkey to do data analysis. In fact, all my experience is in writing GUIs for Ifeffit. I actually have no experience writing SUIs (simian user interfaces). Perhaps one of our eager users would be interested in doing the pioneering work in this field. ;-) B -- Bruce Ravel ----------------------------------- ravel(a)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/

1 0

measurement uncertainty
by Bruce Ravel 22 Oct '02

22 Oct '02

Gustavo de Medeiros Azevedo said: GdMA> I''ve recently started using IFEFFIT, and I'm a bit confused on GdMA> the way it estimates the error bars. In the IFEFFIT Reference GdMA> guide, (page 38) you mention the variables epsilon_k and GdMA> epsilon_r, where the measurement uncertainty is stored. In GdMA> that same page, you remark that changing the values of GdMA> epsilon_k and epsilon_r will change chi_squared, Chi-reduced GdMA> but won't affect R_factor and the error bars. As far as I GdMA> understand, the error bars should given by the diagonal GdMA> elements of the co-variance matrix, multiplied by the square GdMA> root of Chi_reduced. In this way, I would expect that varying GdMA> epsilon_k or epsilon_r should affect the estimated GdMA> uncertainties. GdMA> Could you, please, clarify this point? Gustavo, Well, I live one time zone to the east of Matt, so I guess I'm seeing this before he does ;-) I'll take a stab at your question. epsilon_r is measured from the data by performing the Fourier transform of chi(k) and then computing the root mean square value of the magnitude of chi(R) between 15 and 25 Angstroms. The assumption is that, because of disorder and mean-free-path effects, any finite spectral content in that R range can only be due to white noise in the data. The relationship between epsilon_k and epsilon_r is established by the normalization of the Fourier transform. Because epsilon_R enters into the fitting metric, chi-square, when the fit is done in R-space (or epsilon_k for a fit in k space), you are correct that the value of chi-square and reduced chi-square are affected by the value of epsilon_r. The R_factor is just a percentage misfit and so is independent of epsilon. The error bars are independent of epsilon as reported by ifeffit, but the reason for this requires some explanation. The first question to ask at this point is whether it is valid to presume that the dominant error in the exafs measurement is the shot noise measured from the high-R portion of the Foruier spectrum. In most situations it is not -- that is, in most situations the shot noise is much smaller that detector non-linearity, sample inhomogeneity, errors in the theoretical fitting standards, errors in the empirical fitting standards, or a whole host of other problems you might have in a real experiment. Particularly at 3rd generation light sources, photon flux and the shot noise associated with it is the least of your problems. By a long stretch. Thus, the way ifeffit uses to estimate epsilon is manifestly wrong. It is way too small, thus chi-square is very large. Even for a fit that is clearly a good fit, such as the common example of a copper foil that comes with the Artemis, the reduced chi-sqare is much larger than 1. By the formalism of Gaussian statistics, we expect that a good fit has a reduced chi-square of about 1. So what's going on? Well, the problem is that ifeffit makes no attempt (since it operates within a Gaussian framework and not a Baysian framework) to estimate all the other sources of error besides shot noise. Thus it is almost always doomed to have reduced chi-square much larger than 1 (except in the odd case when the shot noise is quite large). So what about the error bars? The diagonal elements of the covarience matrix (i.e. the error bars) are much too small for the same reason that the reduce chi-square is too large, i.e. because epsilon has been vastly underestimated. Ifeffit then makes the assumption that the fit it just finished was, in fact, a good fit. It assumes that the reason that reduced chi-square is not near one is NOT because it is a bad fit, but rather because epsilon has been significantly underestimated. Multiplying the error bars by the square root of reduced chi-square is mathematically equivalent to re-evaluating the covarience matrix with epsilon set to the value it must be for reduced chi-square to equal 1. Thus, it is the mathematical equivalent of assuming that the fit is, in fact, a good fit. So finally, you asked how setting epsilon to some other value will effect the fit. The answer is "Not much." It will have some small effect in how the fit is evaluated numerically because chi-square may be of a different order of magnitude. However, because Ifeffit rescales the error bars under the assumption that the fit was good, manually changing epsilon will have little effect on the results. One more thing needs to be said. Because Ifeffit *always* assums that the fit is a good fit and reports statistics accordingly, it is the RESPONSIBILITY OF THE USER to actually evaluate the quality of the fit. Are the best fit values physically reasonable? Are the parameters highly correlated? Are the rescaled error bars of a reasonable size? Ifeffit cannot answer those questions. You must. And that, finally, is why a human needs to do data analysis. Sadly we cannot train a computer or a monkey to decide if the fit is, in fact, the one you want to publish. Hope that helps, Bruce -- Bruce Ravel ----------------------------------- ravel(a)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/

2 1

Re: Ifeffit digest, Vol 1 #67 - 1 msg
by Gustavo de Medeiros Azevedo 22 Oct '02

22 Oct '02

Dear Bruce and Matthew, I''ve recently started using IFEFFIT, and I'm a bit confused on the way it estimates the error bars. In the IFEFFIT Reference guide, (page 38) you mention the variables epsilon_k and epsilon_r, where the measurement uncertainty is stored. In that same page, you remark that changing the values of epsilon_k and epsilon_r will change chi_squared, Chi-reduced but won't affect R_factor and the error bars. As far as I understand, the error bars should given by the diagonal elements of the co-variance matrix, multiplied by the square root of Chi_reduced. In this way, I would expect that varying epsilon_k or epsilon_r should affect the estimated uncertainties. Could you, please, clarify this point? Best Regards, Gustavo Azevedo At 12:00 PM 17/10/2002 -0500, you wrote: >Send Ifeffit mailing list submissions to > ifeffit(a)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(a)millenia.cars.aps.anl.gov > >You can reach the person managing the list at > ifeffit-admin(a)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: using Artemis (Bruce Ravel) > >--__--__-- > >Message: 1 >Date: Thu, 17 Oct 2002 09:33:37 -0400 >To: ifeffit mailing list <ifeffit(a)millenia.cars.aps.anl.gov> >Subject: Re: [Ifeffit] using Artemis >Reply-To: ravel(a)phys.washington.edu >From: Bruce Ravel <ravel(a)phys.washington.edu> > > >John, > >I think you replied to me rather than to the list, so I am answering >to list. > >You said: > > jjr> It's great to have the hints on artemis usage. My friendly > jjr> suggestion would be to complement this with sample input/output > jjr> so one can follow along a worked example. The "examples" in the > jjr> artemis source are somewhat useful in this respect, but hacking > jjr> one's way wasn't completely straightford for me. > >I have been thinking about how to provide useful, interactive examples >and documents for the programs. It's difficult. > >The example projects for Artemis are certainly incomplete works-in- >progress. > >There is a README file in the examples directory for Athena that is >helpful, but should, I guess, be an html file. The project files in >both programs' examples directories do have journal entries that help >explain what's going on and give suggestions for other things to do. > >The journals are accessible from the Edit menu in either program and >are a space for writing notes about the project. The journal is saved >in the project file along with all the data. The idea is that you have >a space to record note so that, in 6 months, you can recall why you >did all the wacky things in the project. Not using the journals? You >should be ;-) > > > >So, I agree that the examples are not all they could be. It is >actually hard for me to make good examples since I already know how >the programs work. Good examples are something the people on this >list could put together and contribute. That would be extremely >welcome and an excellent, non-programmer's way of giving something >back to Matt and I. > > > >Regards, >B > > >-- > Bruce Ravel ----------------------------------- ravel(a)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/ > > >--__--__-- > >_______________________________________________ >Ifeffit mailing list >Ifeffit(a)millenia.cars.aps.anl.gov >http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > >End of Ifeffit Digest

1 0

Re: [Ifeffit] using Artemis
by Bruce Ravel 17 Oct '02

17 Oct '02

John, I think you replied to me rather than to the list, so I am answering to list. You said: jjr> It's great to have the hints on artemis usage. My friendly jjr> suggestion would be to complement this with sample input/output jjr> so one can follow along a worked example. The "examples" in the jjr> artemis source are somewhat useful in this respect, but hacking jjr> one's way wasn't completely straightford for me. I have been thinking about how to provide useful, interactive examples and documents for the programs. It's difficult. The example projects for Artemis are certainly incomplete works-in- progress. There is a README file in the examples directory for Athena that is helpful, but should, I guess, be an html file. The project files in both programs' examples directories do have journal entries that help explain what's going on and give suggestions for other things to do. The journals are accessible from the Edit menu in either program and are a space for writing notes about the project. The journal is saved in the project file along with all the data. The idea is that you have a space to record note so that, in 6 months, you can recall why you did all the wacky things in the project. Not using the journals? You should be ;-) So, I agree that the examples are not all they could be. It is actually hard for me to make good examples since I already know how the programs work. Good examples are something the people on this list could put together and contribute. That would be extremely welcome and an excellent, non-programmer's way of giving something back to Matt and I. Regards, B -- Bruce Ravel ----------------------------------- ravel(a)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/

1 0

Athena disappears instantly if a new graph is being presented.
by Bruce Ravel 15 Oct '02

15 Oct '02

Kotoro, This is a question of broad interest. I hope you don't mind that I forward it to the ifeffit mailing list. > On Tue, 15 Oct 2002, "Kotaro Sasaki" <ksasaki(a)bnl.gov> said: KS> Dear Bruce, I was an attender at EXAFS workshop at NSLS last KS> month; I have just updated the syetem of my computer from WINDOW KS> 98 to XP. Now ATHENA seems to run on this system. Yay! Sorry for the hassle. There are just too many operating systems and too few of us working on the software! The situation with 9x/ME is fragile. KS> However I encountered the following problem. When I try to replot KS> a new graph after closing a previous graph, the program is KS> suddenly shot down. This is a known problem with PGPLOT on windows. At this time neither Matt nor I know any better solution than "don't close the plot window." Just get in the habit of NEVER closing the plot window unless you are done with Athena (Same holds true for Artemis) and things should work OK. Regards, B -- Bruce Ravel ----------------------------------- ravel(a)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/

1 0

using Artemis
by Bruce Ravel 14 Oct '02

14 Oct '02

Hi folks, Based on feedback from last months EXAFS course at NSLS and on some email I received last week, I decided there was a need to start working on a beginner's guide to using Artemis and Ifeffit for fitting data. Here is the URL for this new document: http://leonardo.phys.washington.edu/~ravel/software/exafs/startfitting.html Please feel free to send me comments. Feel free to edit it heavily or add material. I would like this to develop into a collaborative, community document. This is not meant to be a comprehensive guide to fitting. Nor is it intended to replace my book of analysis tricks at http://leonardo.phys.washington.edu/~ravel/course/notes/ It is intended to get people over the initial potential barrier of using Artemis and Ifeffit and start them down the road of using them cleverly and intelligently. B -- Bruce Ravel ----------------------------------- ravel(a)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/

1 0

Athena 0.8.003 released
by Bruce Ravel 14 Oct '02

14 Oct '02

Hi! I just updated the source code tarball and the windows executable for Athena. I added several features last week while I was at the synchrotron and wanted to get them out there. New features include: 1. Energy calibration using the mouse. See the end of the Group menu. 2. Data smoothing. The Fourier filter smoothing is flaky and smoothing is a suspicious thing to do in any case. Take this feature with a grain of salt. 3. Save many marked groups as columns in a single data file. See the File menu. This is handy for exporting much data from Athena to a plotting program 4. Fixed a bug whereby the pre-edge line energy range was not being respected. 5. Athena will now tell you how many spline knots it intends to use. See the Data menu. Thanks to Shelly Kelly for the pre-edge bug and thanks to Dean Hesterberg, Suzanne whose-last-name-I-can't-remember, Kumi Pandya, and Mali Balasubramanian for several good suggestions. There are some new notes on the download page for Windows 9x/ME users and a new page about how to write a good bug report. Check 'em out! B -- Bruce Ravel ----------------------------------- ravel(a)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/

1 0

Re ifeffit and Mac OS X
by Jeff Terry 11 Oct '02

11 Oct '02

Hi all, fink is not that hard to use. I believe that the firewall problem is due to the APS blocking the cvs port. I forget which one it is. Jeff

2 1

new release of Athena
by Bruce Ravel 01 Oct '02

01 Oct '02

Hi folks, This morning I posted a new version of the source code package and a new windows executable for Athena on my web site. The changes in Athena include: 1. The ability to read a data file from a multi-element detector and have each channel be made into a separate group. This allows you to examine and discard individual channels before making a summation. 2. Added a simple log-ratio/phase-difference analysis. This can be accessed from the "Analysis" menu. It is currently undocumented, but if you already know how log-ratio works, it should be fairly clear what is going on. 3. Fixed (I think!) a bug in which reading in data and selecting the raw detector data type would crash the program on Windows. 4. Fixed a bug that made it impossible to save chi(q) data correctly. There are some outstanding problems with both the multi-element thing and the log-ratio thing. The most serious of these is one that effects a multi-element file with very many columns. It is quite possible for most of the columns not to be displayed in the column selection dialog. This will be fixed next time. I want to thank Dale Brewe and Oded Kleifeld for their useful bug reports. I also want to thank all of the participants and instructors of the recent EXAFS course at NSLS for putting Athena and Artemis through their paces. Several issues, mostly with Artemis, surfaced at the course and will get my serious attention this fall. *** For those of you receiving this who are not subscribed to the ifeffit mailing list, please consider subscribing. Go to http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit/ and follow the instrctions. *** For those of you wanting to use the new Windows executable of Athena, grab it from the downloads page of my website (URL below in my .sig) and drop it on top of the old one in the C:\Program Files\Ifeffit folder. Please note that the installer has NOT been updated to include it. *** For those of you having strange problems on Windows 98, there are some links on my downloads page that may help you deal with certain inherent limitations of that charming operating system. Regards, B -- Bruce Ravel ----------------------------------- ravel(a)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/

1 0