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

an update on the Mac OSX problem
by Bruce Ravel 28 May '04

28 May '04

Hi, I just wanted to let the mac users know that I have finally flushed out the problem that Stefano and Matt reported. There is most certainly a crippling problem with 0.7.004 on the Mac. In fact, the problm does not have to do with the Mac per se, but with the version of perl/Tk used to build the codes in the Mac installer. As some of you may be aware, the perl/Tk world is in the middle of a transition between two major versions of the toolkit. One of the challanges for me has been to write code that works seamlessly despite certain internal differences. It turns out that I finally traced the problem to a rather obscure difference between the older and new perl/Tk code bases. Fortunately there is an easy solution (although it will take me a while to find all the places where I need to apply it) and I think that I'll be able to post a new source code tar ball by the end of the day. Also fortunately, Windows users will not see this problem using the current builds of the windows executables. Note that the Mac installer currently has 0.7.003, so those who have installed the installer but not updated to 0.7.004 are unaffected. Finally, linux and other unix users who are using a perl/Tk 800 release will be unaffected. The bug is specific to perl/Tk 804. The amusing thing is that Stefano originally reported this as a problem loading an atoms.inp file. That turned out to be quite a red herring. The problem has nothing to do with the part of the code that handles atoms or feff files! Regards, B -- Bruce Ravel ----------------------------------- ravel(a)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/

2 1

Using more than one E0
by Wojciech Gawelda 28 May '04

28 May '04

Hi everybody, I would like to address a couple of questions which are partially related to my recent struggles in fitting some EXAFS data. Im 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 E0s 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 E0s for each path? Thats 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 Im still somewhat confusedhow 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 pathseven if the background parameters dont correlate significantly with fitting parameters I have my doubts whether the result is trustful. Any hints about this procedure? Well, Ill greatly appreciate any comments and feedback from all you guys. I hope Ill be able to share some of my own soon :-) 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: <mailto:wojciech.gawelda@epfl.ch> wojciech.gawelda(a)epfl.ch WWW: <http://lsu.epfl.ch> http://lsu.epfl.ch *********************************************************************

4 7

Question about the R_factor in artemis/ifeffit
by Wayne Lukens 28 May '04

28 May '04

Dear Matt and/or Bruce, First, thank you for the great software! I am a former EXAFSPAK user and have been really impressed by Artemis/ifeffit. It's easier to use, more flexible, and gives more reasonable errors for the fit parameters. My question is about the value of the R_factor for R-space fitting. This seems to be the R_factor for the real component of the Fourier transform only although the fitting is performed on both the real and imaginary components. Is there a reason that the contribution of the imaginary component to the R_factor is not included? Sincerely, Wayne --- Wayne Lukens Scientist Lawrence Berkeley National Laboratory email: wwlukens(a)lbl.gov phone: (510) 486-4305 FAX: (510) 486-5596

4 14

RE: Using more than one E0 correction
by Wojciech Gawelda 28 May '04

28 May '04

Hi everybody, I would like to address a couple of questions which are partially related to my recent struggles in fitting some EXAFS data. Im 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 E0s 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 E0s for each path? Thats 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 Im still somewhat confusedhow 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 pathseven if the background parameters dont correlate significantly with fitting parameters I have my doubts whether the result is trustful. Any hints about this procedure? Well, Ill greatly appreciate any comments and feedback from all you guys. I hope Ill 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(a)epfl.ch WWW: http://lsu.epfl.ch ********************************************************************* -----Original Message----- From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of ifeffit-request(a)millenia.cars.aps.anl.gov Sent: jeudi, 27. mai 2004 18:46 To: ifeffit(a)millenia.cars.aps.anl.gov Subject: Ifeffit Digest, Vol 15, Issue 23 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-owner(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: 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(a)anl.gov> Subject: RE: [Ifeffit] Autobk parameters To: "XAFS Analysis using Ifeffit" <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <1C1577844A0BDF448E14E8CCB2F7442401006AF1(a)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(a)phys.washington.edu> Subject: Re: [Ifeffit] Autobk parameters To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <200405261656.37396.ravel(a)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(a)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(a)unibo.it> Subject: Re: [Ifeffit] Autobk parameters To: ravel(a)phys.washington.edu, XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <a06100508bcdb9b73cde8(a)[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(a)unibo.it> Subject: Re: [Ifeffit] Autobk parameters To: ravel(a)phys.washington.edu, XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <a06100507bcdb99ed729e(a)[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(a)ECE.NEU.EDU> Subject: [Ifeffit] A saving problem in newest Artemis version To: <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <000001c4440a$2e89efd0$443d0a81@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

2 1

A saving problem in newest Artemis version
by Aria 27 May '04

27 May '04

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

1 0

RE: [Ifeffit] Autobk parameters
by Kelly, Shelly D. 26 May '04

26 May '04

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

1 0

Autobk parameters
by Stefano Ciurli 26 May '04

26 May '04

Hi folks, guess what, another question... I would like to estimate the area of a small pre-edge peak in a Nickel spectrum. It is known that the area of this peak, compared to the XANES, is correlated to the degree of symmetry for the Ni(II) ion. I tried to use the peak fitting procedure implemented in Athena, but unsuccessfully. If I limit the fitting region to close to the pre-edge peak, and use either gaussian or lorentzian lineshape, the fitting is bad, really bad (shift of the fitted maximum, wrong linewidth). Maybe the peak is just too small. If I try to fit the entire XANES in addition to this small peak, I get very good fit for the XANES features, but negative intensities for the pre-edge peak. Any clues? 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

2 1

[help] ifeffit -i = segmentation fault
by mauro＠rulp.org 26 May '04

26 May '04

Hi to all, I'm having big troubles with iFEFFIT. I have updated the systems (Linux GNU Debian/ Testing) and I realized that version 800.025 of perl-tk was automatically installed. After that, obviously, everything crashed with Artemis and friends. So I have downgraded perl-tk to 800.024 using a non standard debian package (because the standard one requires perl-base 5.6.1 and I'm working with perl-base 5.8.3) from here: http://snapshot.debian.net/cgi-bin/packages.cgi (I have used perl-tk_800.024-1.2_i386.deb) After that I decided to recompile everything... bad idea! ifeffit-1.2.5 recompiled fine (no errors appeared in the configure/make/make install process). *BUT* when I try to recompile horae-034 it crash on determining ifeffit version. In fact, if I run "ifeffit -i" it gives me: Segmentation fault (Killed, on another machine) I hope someone could help me because at the moment I can do nothing! :( Thanks, Mauro -- Mauro Rovezzi <mauro(a)rulp.org> - Physics student University of Rome "Tor Vergata", ESRF Beamline BM8 - GILDA

5 14

athena 0.8.028, artemis 0.7.004, and hephaestus 0.02
by Bruce Ravel 25 May '04

25 May '04

Hi folks, I have just posted a new source code package for my codes on my web page and on SourceForge. You can now run the horae_update script. I have also assembled the contents of the Windows updater, which should be available in the next few days. When it is ready, the windows updater will notice and update you automatically. Along with many bug fixes and feature enhancements in Athena and Hephaestus, there are a large number of improvements in Artemis. As you all no doubt remember, there were quite a large number of serious bugs reported after the last release of Artemis. With the generous and patient help of several users I was able to understand and correct about two dozen problems leading to all sorts of misbehavior ranging from simple trap file generation to program crashes. I am guardedly optimistic that you will find the new release to be a significant improvement over the last in terms of stability and usability. Among the big new features of Artemis are: 1. An revamped Guess, Def, Set page with lots of new features. I'll be sending out an email later this afternoon explaining the new GDS page. 2. The ability to clone feff calculations. This will be very helpful for those of you doing multiple data set fits. This, too, will get its own email later today. 3. New ways of viewing the log file. 4. Expanded information about each path displayed on the paths page. and lots of minor enhancements. See the change log on my web site for the complete list. One caveat -- I once again made some changes to the format of the artemis project file. I will not be able to guarantee stability of the project file format for a long time to come. I'll make sure Artemis can read in project files from previous versions, but it is likely that any new version will write a project file that cannot be completely imported by older versions. That's just one more reason to stay up-to-date! Several people get an acknowledgement for their contributions to this release: David Barton, Gerrit Schmithals, Aria Yang, Scott Calvin, Peter Southon, and Dogan Paktunc all deserve a tip of the cap for excellent suggestions and useful bug reports. Shelly Kelly was amazingly generous with her time in the last few weeks helping me to debug the current version. She also helped me design the new GDS page and pushed me to add several of the other new features in the code. All of you should buy Shelly a beer the next time you see her -- I certainly will! As always, let me know what suggestions you have or problems you run into. Bruce -- Bruce Ravel ----------------------------------- ravel(a)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/

3 4

that didn't take long...
by Bruce Ravel 24 May '04

24 May '04

Hi, Once again a serious bug has cropped up in artemis within 24 hours of a new release. Sigh... I'm pretty good at the first 95% of making a new release, but I seem to suck at the last 5%! ;-( The problem this time is in trying to do the background corefinement. If you click on the "Fit background" button, the fit will run to completion but the log file will not be written. Fortunately, the fix is extremely simple. I will post a new source code tarball by the end of the day. I will also try to get a new executable built so that the windows updater can be updated. Until then, you should consider background corefinement to be broken. Thanks go to Gleb Pokrovski for pointing this out (as well as racing out to try the new version!). B -- Bruce Ravel ----------------------------------- ravel(a)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/

2 2