[Ifeffit] RE: Using more than one E0 correction
Wojciech Gawelda
wojciech.gawelda at epfl.ch
Thu May 27 13:51:40 CDT 2004
Hi everybody,
I would like to address a couple of questions which are partially
related to my recent struggles in fitting some EXAFS data. I’m trying to
fit my data using several shells of different neighbors including a few
single scattering paths and also so multiple scattering contributions
(mainly collinear multiple scattering paths) all calculated with the
help of FEFF 8.20. Now, I found once in the FEFFIT manual the following
suggestion: one might consider using several different E0’s for
different paths in order to improve the fit. Ok, the explanation was
based on some approximations coming from FEFF code which include
incomplete core-hole shielding, lack of angular variations of the
valence charge distribution and charge transfer between atoms in polar
materials.
My question is the following: does anyone of you have some experience
with such procedure? And if yes, shall than distinguish between the
first shell of nearest neighbors and the rest of the atoms in terms of
their E0 corrections (using 2 parameters)? Or perhaps one can use
separate E0’s for each path?
That’s one thing
The second question concerns the background correction in Artemis: I was
trying to find an easy explanation of what this procedure does during
the fit but I guess I’m still somewhat confused
how one can judge
whether the spline co-refinement does the right job? Some people on this
mailing list underline that one should avoid high correlations between
fitting parameters and background parameters in order to make sure that
the fit is correct. But is it the only criterion? In some of my fits
background line looks kind of constant over the entire R-range which was
taken into the fit. Sometimes it becomes like a modulation peaking
underneath some scattering paths
even if the background parameters don’t
correlate significantly with fitting parameters I have my doubts whether
the result is trustful. Any hints about this procedure?
Well, I’ll greatly appreciate any comments and feedback from all you
guys. I hope I’ll be able to share some of my own soon J
Cheers,
Wojciech
*********************************************************************
Wojciech Gawelda
Laboratoire de Spectroscopie Ultrarapide (LSU)
Institut des Sciences et Ingénierie Chimiques (ISIC),
Faculté des Sciences de Base (SB-BSP)
Ecole Polytechnique Fédérale de Lausanne (EPFL)
CH-1015 Lausanne-Dorigny, Switzerland
Tel.: +41 (21) 693 0452
Fax.: +41 (21) 693 0422
E-mail: wojciech.gawelda at epfl.ch
WWW: http://lsu.epfl.ch
*********************************************************************
-----Original Message-----
From: ifeffit-bounces at millenia.cars.aps.anl.gov
[mailto:ifeffit-bounces at millenia.cars.aps.anl.gov] On Behalf Of
ifeffit-request at millenia.cars.aps.anl.gov
Sent: jeudi, 27. mai 2004 18:46
To: ifeffit at millenia.cars.aps.anl.gov
Subject: Ifeffit Digest, Vol 15, Issue 23
Send Ifeffit mailing list submissions to
ifeffit at 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 at millenia.cars.aps.anl.gov
You can reach the person managing the list at
ifeffit-owner at 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: Autobk parameters (Kelly, Shelly D.)
2. Re: Autobk parameters (Bruce Ravel)
3. Re: Autobk parameters (Stefano Ciurli)
4. Re: Autobk parameters (Stefano Ciurli)
5. A saving problem in newest Artemis version (Aria)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 May 2004 12:18:01 -0500
From: "Kelly, Shelly D." <SKelly at anl.gov>
Subject: RE: [Ifeffit] Autobk parameters
To: "XAFS Analysis using Ifeffit" <ifeffit at millenia.cars.aps.anl.gov>
Message-ID: <1C1577844A0BDF448E14E8CCB2F7442401006AF1 at ANLMAIL.anl.gov>
Content-Type: text/plain; charset="us-ascii"
Hi Stefano,
> 1) I understand that energy calibration should be performed, and I
> did so by using the atomic edge energy. I also understand that this
> parameter could be fluctuating in the subsequent fitting. Any comment
> on this procedure?
I agree that all the energy shift stuff can be confusing. The important
end result for Extended X-ray Absorption Fine Structure Analysis is to
get the energy-grid of the data to match the energy-grid of the theory
with the zero energy of the photo-electron somewhere on the absorption
edge. In the process of doing this you may have more than one data set
from the same sample with different energy-grids... Furthermore you may
have more than one sample which may have different energy-grid from the
other samples and the theory. Then to make things all the more
complicated X-rays can change the oxidation state of metals in organic
materials. So that the energy grid is supposed to be different and the
data is useless.
After all that, here are some answers.
1) Always measure a foil reference at the same time that you measure any
EXAFS data. It is easy to do. Here is a reference for how to do it
when your sample is too thick and you can not simply put the foil behind
the It ion chamber. J L Cross and A I Frenkel. "Use of scattered
radiation for absolute energy calibration." Rev. Sci. Instrum. 70: pp
38-40, 1998
2) Align each data scan:
2a) Without an energy reference. Align the data to one of the data sets
(remember which one you used) so that the edges are all right on top of
each other. Each sample has it's own energy-grid.
2b) By using the energy reference of the foil measured simultaneously
with each scan. Align all the reference spectra to one of the
reference spectra. Then shift each of the data sets that belong to the
reference spectra by the same amount. Now each scan is independently
aligned and you have an absolute energy reference for each scan. This
is useful for XANES comparisons or if you suspect changes in the data
while the measurement was taking place. The difference in energy from
the reference to the data or from one data set to another is a real
change and can be used to "say" stuff about the sample.
3) Check the alignment: Plot all the normalized xmu(E) data from the
same sample in Athena, zoom in on the edge region -20 to 20 eV and take
a good look. Hopefully they all line up. If there is a systematic
change in the edge features? If so how much...less than 10 % (which is
about the accuracy of the measurement). This means that you can most
likely still use the data but that you have changes happening to your
sample while the measurement was taking place and you should fix that
next time.
4) Now the problem of alignment is somewhat smaller. All the data sets
have the same energy grid if you used 2b...or all the data sets have
there own energy grid if you used 2a. Now we need to align the data and
the theory. To do this there are two steps. Choosing a zero energy of
the photo-electron to define the k-grid in converting the data to
chi(k), and then aligning the chi(k) data with the theory chi(k).
5) Choosing a Ezero in Athena: Pick any point that you like on the edge
for Ezero in Athena. Plot the xmu data with the background and pre-edge
and post-edge range. A circle on the plot shows the position of Ezero.
Then right click The Ezero to set this energy to be the same value for
all the data sets from this sample. Then plot the chi(k) data and see
that the curves all look the same at low k-values. If not adjust Ezero a
bit for the data sets that are different to get the chi(k) data to look
the same. Then average the chi(k) data and write it out so that you can
align it with the theory in Artemis.
6) Aligning data to theory: Read the data into Artemis. Read in what
you think should work for a first shell feffxxxxx.dat file. Fit the
data to the first shell. Plot the data and the theory in chi(k), take a
look at the deltaE value from the fit. This value for deltaE is telling
you how much the theory had to move to match-up with your choice of
Ezero that you picked in step 5. If you think that the theory is
correct and deltaE is larger than a few eV then you need to adjust your
chi(k) data. But first write out what the theory should look like if
you choose Ezero just right.
6b) Making a standard: In Artemis, set all the parameters to their
best-fit values, except for deltaE. Set deltaE to zero and run the fit
again. This is not really a fit. There are no parameters to optimize.
Now the theory is showing you what the data should look like if you
choose the perfect value for Ezero and the perfect background function
in step 5.
7) Redo the background and energy choice: In Athena open up the
chi(k).fit that was produced by step 6b. This is the "standard" that
you can use to help get Ezero and the background correct. Then select
individual scans taken from the sample and then open the standard menu
and choose the theory chi(k) data. Right click on the standard to use
the same standard for all data sets. Redo the background removal. Plot
the chi(k) data and the standard. If they are different at low k you
need to adjust Ezero so that they start at the same place. When you are
done adjusting your choice for Ezero, plot the xmu(E) data and make sure
that the circle that is your value for Ezero is on the edge. If it
isn't, then the theory that you used to align the data doesn't work..and
you need to start over in step 6. If the value is on the edge some
where, right click on the Ezero choice and set its value for Ezero of
all the scans. Then merge all the data in chi(k) and write it out for
use in Artemis...as you did the first time making sure that all the
scans have a similar bkg.
8) Redo the fit: Now the data and the theory are aligned and you can
redo the fit varying all the parameters...deltaE in Artemis should be
small..and the background should give a nice match at low-r values.
Often this entire procedure is used at the end of your analysis to make
a nice figure for publication.
9) Bonus of using an energy reference: If you used an energy reference
measured simultaneously with the data sets then in the end you can
simultaneously fit the different samples with only one deltaE in the fit
for all of the samples. If you aligned each one independently then each
data set should have it's own deltaE value..unless you have more
information and can prove that they should be the same.
HTH
Shelly
------------------------------
Message: 2
Date: Wed, 26 May 2004 16:56:37 -0400
From: Bruce Ravel <ravel at phys.washington.edu>
Subject: Re: [Ifeffit] Autobk parameters
To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
Message-ID: <200405261656.37396.ravel at phys.washington.edu>
Content-Type: text/plain; charset="iso-8859-1"
Okee dokee, a few more thoughts after Matt's and Shelly's posts...
SC> 2) The next parameter is Rbkg. I have read the literature about this
SC> parameter, especially the 1993 paper by Matt. I sort of understood
SC> the rationale and method, but I also gathered that the default
SC> parameter of 1.0 can be changed. What are the criteria for changing
SC> this? I tend to keep it to the default value, but I feel a bit
uneasy
SC> about not being able to control this parameter intelligently.
Unfortunately there is not a really good rule of thumb. One might say
"half the distance to the first peak", but that's not really a very
good rule. The issue is that choice of Rbkg can have a profound
impact on the low frequency Fourier components. (Try setting Rbkg to
an absurdly large value, say 2 or 3, and see what damage that does to
your data!)
I would say the real answer is that the choice of Rbkg shouldn't be
too strongly correlated with the things you are trying to measure --
N, delta_R, sigma^2. Once you have set up your fitting model in
Artemis, a little experiment to try is to save chi(k) using several
different values of Rbkg and see how the answers change when you do
the fits.
To completely make up an example, suppose that you save chi(k) for
Rbkg=0.75 and 0.95, then do the fits. If the best fit values of N,
delta_R and so on are the same within their error bars, then it
doesn't matter which Rbkg you use in Athena. In that case you would
probably use the larger one because it probably makes the "prettier"
picture in terms of removing very low frequency Fourier components.
SC> 3) I understood from the paper by Matt (and from the "Using Athena"
SC> manual by Bruce) that one could use a "standard" to estimate the
SC> level of leakage into the small chi(R) region (apodization effects
SC> due to Fourier window filtering). The manual states that one can
read
SC> in a chi.dat file produced with feff. However, I do not understand
SC> how to build the feff.inp for feff and produce a useful chi.dat to
SC> use as a "standard". Please help?
In your follow-up to my original answer to this question, you made it
clear that the role of the standard is still not clear to you.
As Matt said, the standard need not be perfect. Let me explain why.
The autobk algorith works by "optimizing" the low frequency Fourier
components in order to select the correct spline function. In the
absence of a standard, "optimize" means "minimize". That is, without
a standard, autobk finds the spline that makes the chi(R) spectrum as
small as possible between 0 and Rbkg.
Again as Matt said, low Z ligands often benefit by using a standard.
The reason is that low Z ligands tend to have quite short distances
resulting in a peak in chi(R) that has a significant tail into the
region below Rbkg. In that case, *minimizing* the components between
0 and Rbkg is a poor idea because they are *supposed* to be non-zero.
A standard then is used to tell the autobk algorithm what the
components between 0 and Rbkg are supposed to look like and the spline
is chosen to make the data look that way between 0 and Rbkg. In that
context, the standard need not be perfect -- close should be good
enough.
Oh yeah. The feff run should produce a file called "chi.dat". That's
a good one to use as a standard. Matt's ifeffit recipe for converting
a feffNNNN.dat file into a chi(k) works, too.
SC> 4) Then there is the k-weight parameter to be changed for the
SC> background removal. The default value for this is 1, but higher
SC> values are allowed. I noticed that increasing the k-weight for
SC> background removal produces a curve in the chi(E) which more and
more
SC> appear to disregard the edge peak, resembling more and more a
SC> smoothly monotonically increasing curve. Consequently, the chi(k)
SC> changes depending on this parameter, and I again start to be worried
SC> about the following fit of it. What are the criteria to choose this
SC> k-weight for the background?
With noisy spectra, the high energy portion of the data might be
dominated by fluctuations that have nothing to do with the exafs. In
that case a large k-weight for the background removal might be unduly
influenced by stuff that is not the data you want to analyze but
instead are detector problems, sample inhomogeneity problems,
gremlins, crap, whatever ;-)
SC> 6) Spline range: this is another important issue, I think. In the
SC> paper by Matt it is stated that "standard practice ... has been to
SC> ignore everything below an energy typically 30 eV above the E0" and
SC> that Autobk is an advantage because it can read in data very close
to
SC> the E0. My question is: the default value for k in the spline range
SC> is set to 0.5 eV (0.952 eV). What are the criteria to change this
SC> default value? Also, is there any relationship between this range
and
Matt said:
MN> I typically use kmin=0, kmax=last_data_point, dk=0 for the spline
MN> (which are the defaults). Bruce seems to prefer kmin=0.5 or so:
MN> it shouldn't make a difference.
The reason I chose to make 0.5 the default is so that Athena will
stand a better chance of dealing well with data that have a large
white line. For data like that spline_kmin=0.0 often leads to a poor
background removal because the spline just doesn't have the freedom to
deal with such a quickly changing part of the spectrum. For many
materials 0.0 is probably a better choice, but in Athena I want the
default behavior to always be non-stupid. ("Smart" is a bit too
difficult for me ;-)
SC> the range subsequently used for FT? My guess is that the k-min for
FT
SC> should be always higher that the k-min for the spline range, but
SC> please comment on this. Also, what are the criteria to set the
Well, the FT range must be equal to or smaller than the spline range,
but you probably already figured that out! Other than that there is
not relationship. It is certainly useful in practice for them not to
be the same.
Getting back to the problem of deling with a white line, I often find
it useful to make spline_kmin 1 or even larger to avoid the white line
altogether. That means that the FT range will also be smaller
resulting in less data for fitting, but it seems worth it. Since it
is so hard to distinguish data from background under the white line,
it is often better to just avoid the problem altogether.
SC> 7) for the FT parameters: Shelly's protocol to define the k-range to
SC> best calculate the chi(R) was clear and useful to me. However, I
SC> would like to know more about choosing the dk parameter and the
SC> window-type. I need some general criteria to choose between the
SC> various possibilities. I noticed that the kaiser-bessel window is
SC> the default, but in the literature I almost invariably find the
SC> Hanning window. Please comment.
Matt summed this up. (I liked the historical context!) Here is a
talk that Shelly gave last year at the NSLS exafs course:
http://cars9.uchicago.edu/xafs/NSLS_EDCA/July2003/Kelly.pdf
Check out page 21. It demonstrates really clearly how little the
choice of window shape matters.
As for dk, I don't have a good rule of thumb. I generally choose a
smallish number.
I wanted also to say a few words about your question regarding peak
fitting. In a numerical sense, peak fitting is harder than fitting
exafs spectra. An exafs spectra is basically one or more damped sine
waves. If you try to fit that with any ol' damped sine wave that's
not too far out of phase, you won't go too far wrong.
The same is not true of fitting peak shapes to xanes data. That kind
of non-linear fit is notoriously unstable. In my experience, it can
be very difficult to fit the centroid of a peak shape to a feature in
a xanes spectrum. That is why Athena has the centroid not flagged as a
variable by default.
I am not completely clear on what's going on with your data, but it
seems as though you want to fit a very tiny feature at the very
beginning of the data. The problem there is that, if the pre-edge is
not completely flat, the lineshape used for the edge step might
through the peak or well below the peak. If so, the peak shape you
are trying to use to fit that feature might be poorly defined
numerically.
I would recommend trying to adjust the parameters by hand until you
geta fairly decent representation of the data, then let some of the
parameters float in a fit to start understanding where the parameters
will want to float off to.
If you try to fit the whole xanes spectrum in one quick swoop, though,
you are indeed likely to get a poor fit.
SC> I feel like a naive cook who is afraid of making mistakes, and
SC> therefore reads a receipe very carefully, not to mix the wrong
SC> ingredients in the wrong amounts. So, again, please bear with me.
Well, I have enjoyed cooking my entire life and I like to think I am
not so bad at it. In my experience, the one way to truly learn how to
make a really good dish is to make some bad ones and think about what
went wrong. You'll know when you're getting there because the dish
will start to taste good.
The same applies to using the codes. Poke at the buttons and don't
fret if weird stuff happens. Think about what it means and why the
weird results are inconsistent with what you know about your sample.
Eventually the results from the analysis will start to make sense in
the context of what you know about your samples. Mmmmmm.... that's
good analysis!
B
--
Bruce Ravel -----------------------------------
ravel at phys.washington.edu
Code 6134, Building 3, Room 405
Naval Research Laboratory phone: (1) 202 767
2268
Washington DC 20375, USA fax: (1) 202 767
4642
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/
------------------------------
Message: 3
Date: Thu, 27 May 2004 15:21:49 +0200
From: Stefano Ciurli <stefano.ciurli at unibo.it>
Subject: Re: [Ifeffit] Autobk parameters
To: ravel at phys.washington.edu, XAFS Analysis using Ifeffit
<ifeffit at millenia.cars.aps.anl.gov>
Message-ID: <a06100508bcdb9b73cde8@[137.204.93.158]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Bruce,
>SC> 4) Then there is the k-weight parameter to be changed for the
>SC> background removal....What are the criteria to choose this
>SC> k-weight for the background?
>
>With noisy spectra, the high energy portion of the data might be
>dominated by fluctuations that have nothing to do with the exafs. In
>that case a large k-weight for the background removal might be unduly
>influenced by stuff that is not the data you want to analyze but
>instead are detector problems, sample inhomogeneity problems,
>gremlins, crap, whatever ;-)
so I conclude that I should use a LOW k-weight in my case, right?
Stefano
--
____________________________________________
Stefano Ciurli
Professor of Chemistry
Department of Agro-Environmental Science and Technology
University of Bologna
Viale Giuseppe Fanin, 40
I-40127 Bologna
Italy
Phone: +39-051-209-6204
Fax: +39-051-209-6203
"Fatti non foste a viver come bruti,
ma per seguir virtute e canoscenza"
Dante Alighieri - Inferno - Canto XXVI
------------------------------
Message: 4
Date: Thu, 27 May 2004 15:18:21 +0200
From: Stefano Ciurli <stefano.ciurli at unibo.it>
Subject: Re: [Ifeffit] Autobk parameters
To: ravel at phys.washington.edu, XAFS Analysis using Ifeffit
<ifeffit at millenia.cars.aps.anl.gov>
Message-ID: <a06100507bcdb99ed729e@[137.204.93.158]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Hi Bruce,
>Oh yeah. The feff run should produce a file called "chi.dat". That's
>a good one to use as a standard. Matt's ifeffit recipe for converting
>a feffNNNN.dat file into a chi(k) works, too.
when I run feff, I do not get any chi.dat file. Why? I tried to use
artemis to do that, but right now the new version I installed crashes
when I try to read in a feff calculation (which btw I performed on
something that should be similar to my metal site and was about to
use it for standard...) The trap message states:
# Artemis 0.7.004
# This file created at 12:59:30 on 27 May, 2004
# using darwin, perl 5.008001, Tk 804.027, and Ifeffit 1.2.5
# Workspace: /Users/stefano/.horae/stash/artemis.project.0/
The following message was trapped by Artemis on a SIGDIE:
Artemis0.7.004die/Users/stefano/.horae/stash/ARTEMIS.TRAPCODE(0x1e38760)
/Users/stefano/.horae/stash/artemis.project.0/
at /Applications/Ifeffit/bin/artemis line 1550
main::__ANON__('Callback called exit.\x{a}') called at
/Applications/Ifeffit/bin/artemis line 0
Stefano
PS: I am using the OSX 10.3 version
--
____________________________________________
Stefano Ciurli
Professor of Chemistry
Department of Agro-Environmental Science and Technology
University of Bologna
Viale Giuseppe Fanin, 40
I-40127 Bologna
Italy
Phone: +39-051-209-6204
Fax: +39-051-209-6203
"Fatti non foste a viver come bruti,
ma per seguir virtute e canoscenza"
Dante Alighieri - Inferno - Canto XXVI
------------------------------
Message: 5
Date: Thu, 27 May 2004 12:46:39 -0400
From: "Aria" <fyang at ECE.NEU.EDU>
Subject: [Ifeffit] A saving problem in newest Artemis version
To: <ifeffit at millenia.cars.aps.anl.gov>
Message-ID: <000001c4440a$2e89efd0$443d0a81 at harrispc>
Content-Type: text/plain; charset="us-ascii"
Hi folks,
First, thank Bruce and Matt so much for their non-stopping work in
updating
those beautiful pieces of software.
Somehow, another problem occurred to me after the auto-updating days
ago. I
am not sure if this only happened to me. Artemis so far has no problems
in
dealing with those project files which were created by the old versions.
But
when I tried to create a new project importing more than one FEFF
calculations, after I saved and tried to reload it, Artemis simply
failed to
do so. The only FEFF path showed in the 'Data & Paths' panel is the
first
path in the first FEFF calculation.
This is the message I copied from echo:
Opening project zipfile C:/.../artemis60mT_C_100 ...
Opening project zipfile artemis60mT_C_100 ... done!
Doing intrp for CuOct ...
Doing intrp for CuOct ... done!
Artemis trapped a warning! Message dumped to C:\Program
Files\Ifeffit\horae\stash\ARTEMIS.TRAP
The artemis.trap files is shown as below:
# Artemis 0.7.004
# This file created at 12:28:24 on 27 May, 2004
# using Windows XP, perl 5.006001, Tk 800.024, and Ifeffit 1.2.5
# IFEFFIT_DIR is C:\Program Files\Ifeffit
# Workspace: C:\Program Files\Ifeffit\horae\stash\artemis.project.1\/
The following message was trapped by Artemis on a SIGWARN:
Artemis0.7.004warnC:\Program
Files\Ifeffit\horae\stash\ARTEMIS.TRAPCODE(0x3372680)C:\Program
Files\Ifeffit\horae\stash\artemis.project.1\/ at artemis line 1551
main::__ANON__('Tk::Error: could not open C:\Program
Files\Ifeffit\horae\stash\a...') called at blib\lib\Tk.pm (autosplit
into
blib\lib\auto\Tk\Error.al) line 402
Tk::Error('MainWindow=HASH(0x387c174)', 'could not open
C:\Program
Files\Ifeffit\horae\stash\artemis.proj...',
'[\&main::dispatch_read_data]',
'(menu invoke)') called at /PerlApp/Tk.pm line 340
eval {...} called at /PerlApp/Tk.pm line 340
Tk::MainLoop() called at artemis line 1695
When I click on the only path, another warning is trapped:
# Artemis 0.7.004
# This file created at 12:39:51 on 27 May, 2004
# using Windows XP, perl 5.006001, Tk 800.024, and Ifeffit 1.2.5
# IFEFFIT_DIR is C:\Program Files\Ifeffit
# Workspace: C:\Program Files\Ifeffit\horae\stash\artemis.project.1\/
The following message was trapped by Artemis on a SIGWARN:
Artemis0.7.004warnC:\Program
Files\Ifeffit\horae\stash\ARTEMIS.TRAPCODE(0x3372680)C:\Program
Files\Ifeffit\horae\stash\artemis.project.1\/ at artemis line 1551
main::__ANON__('Use of uninitialized value in split at artemis
line
5800, <PROJ>...') called at artemis line 5800
main::populate_path('data0.feff0.0') called at artemis line 2475
main::display_properties('Tk::Ev=SCALAR(0x3327260)',
'data0.feff0.0', 0, 'imagetext', 'body') called at /PerlApp/Tk/Widget.pm
line 988
eval {...} called at /PerlApp/Tk/Widget.pm line 988
Tk::Widget::Callback('Tk::Tree=HASH(0x32d2c3c)', '-browsecmd',
'data0.feff0.0', 0, 'imagetext', 'body') called at /PerlApp/Tk/HList.pm
line
181
Tk::HList::Button1('Tk::Tree=HASH(0x32d2c3c)') called at
/PerlApp/Tk.pm line 340
eval {...} called at /PerlApp/Tk.pm line 340
Tk::MainLoop() called at artemis line 1695
I am not sure the information is enough. Hope it helps.
Best regards,
Aria
-------------- next part --------------
A non-text attachment was scrubbed...
Name: artemis60mT_C_100
Type: application/octet-stream
Size: 27958 bytes
Desc: not available
Url :
http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20040527/
7de9acf6/artemis60mT_C_100.obj
------------------------------
_______________________________________________
Ifeffit mailing list
Ifeffit at millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
End of Ifeffit Digest, Vol 15, Issue 23
***************************************
More information about the Ifeffit
mailing list