Bruce:
I have encountered some strange behavior at the Bi L3 edge.
I have a file which runs out about 1200eV above the edge (13419eV). While
Athena does find the high energy when setting the default normalization
and spline ranges, it does not plot any of the data beyond 14220 (about
800eV above the edge). In fact, there seems to be a hard limit of about
800eV above the edge for all data and this translates into the k-space
plot as well. I am now unsure of what effect this might have on the back
transform if the defaults are not touched but certainly the graphical
setting of limits for normalization, spline fit, fourier transform and
back transform wil not work since the plot does not show the complete data
range.
Another problem I have found is that the Auto Align feature is somewhat
unreliable and does not always yield a visually correct shift. I haven't
characterized when exactly this happens but it has seemed to work once on
a file and then not work later on the same two files.
Cheers,
Carlo
--
Carlo U. Segre -- Professor of Physics
Associate Dean for Research, Armour College
Illinois Institute of Technology
Voice: 312.567.3498 Fax: 312.567.3494
Carlo.Segre(a)iit.edu http://www.iit.edu/~segre
Hi folks,
I received this question today:
> The third question is about the fitting templates provided in your
> software, such as firstshell, mixedshell, three shell, etc. How
> can I predict which one is good for the fitting? What are the
> differences among them?
A bit of recent history. The templates are a feature of Artemis that
I started working on just prior to last month's EXAFS course at NSLS.
The concept seemed to be working pretty well for copper metal
($ironic_mode=1), so I decided to put the templates in the official
release.
The thing that the templates have been most useful for so far is to
point out that Artemis remains almost completely undocumented. The
templates are but one confusing part of the program. Once a user gets
confused, there is no place (other than, of course, this mailing list)
for the user to turn for information. Sigh.
Let me start by explaining what the templates are not:
They are not intended to be a complete description of any fit to any
data set. That is, you cannot expect to choose an item from the
Templates menu, click the big green fit button, and be ready to
publish.
The templates are intended to help you start a new fitting project by
filling in many of the little entry boxes scattered throughout the
program with reasonable first guesses for interesting parameters.
Another way to say this is that the templates will hopefully help save
you from having to do a certain amount of really tedious typing.
As an example, the template called "firstshell" makes a non-stupid
guess about what kinds of parameters you might want for a fit to the
first shell of your data. You will almost certainly have to edit the
guess/set/def parameters as well as the path parameters to get a fit
to your data that is statistically valid and physically reasonable.
Some of the templates ("threeshell" for example) do nothing at all at
this time.
So, to answer the questions directly:
> How can I predict which one is good for the fitting?
In a sense, none of them are. However, if you want to do a fit to the
first shell, the "firstshell" template may be helpful. If you want to
do a fit for which the correlated Debye model is valid, the "debye"
template may be helpful.
> What are the differences among them?
Their names tend to explain the kind of situation in which they might
be helpful.
Let me end by saying my main point one more time in different
language:
Templates are the *starting points* for fits. Use them in that
sense. They are NOT complete fitting models. Do not use them as
such.
Hope that helps,
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/
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/
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/
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
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/
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/
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/
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/
