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

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 27 May '04

27 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

New horae library setup
by Paul Fons 24 May '04

24 May '04

I was going to roll my own version of the latest incarnation of horae, but I noticed the library structure and install location has changed (at least on os x). Can you elaborate on this (Matt or Bruce)? Better yet, is there a tar image of the source available for the mac os x version. Earlier I upgraded perl to 5.8.3 and then the older Tk broke so I was off on my own, so I was compiling everything myself, but now that the install is becoming more and more os x aware (thanks to Matt) it would seem to make sense to downgrade to Apple's older perl (which has prebinding enabled). Of course, now it only makes sense to get in sync with the official sources. Would it be possible to put up the sources on your web site Matt? Paul (an Italian (Elettra) for a ten days)

2 2

graphics and fit
by Stefano Ciurli 22 May '04

22 May '04

Hello, just a thought: wouldn't it be nice to be able to read the feff.inp file directly into a simple molecular graphics program in order to see if the used coordinates contain any error? Maybe it is possible already and I am not aware of it. I understand that the program is mainly used by material scientists, but for us working with biological samples of metalloproteins it would be nice. Another suggestion: I know that Excurve is able to treat the histidine rings as a unity, and when performing the fit that program is able to maintain the ring rigid while fitting the distance between the metal and the imidazole ring of the histidine. How can I do that simply using your suite? 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

4 11

a cautionary tale
by Peter Southon 21 May '04

21 May '04

Hello fellow Ifeffiters This a story about making feff.inp input files for FEFF. The more experienced readers of this list will probably be well aware of the issues involved, but I thought that relative newcomers such as myself might not know (which is why I'm posting this on the Ifefft list rather than the Feff list). In a nutshell, it is wise to create a large cluster of atoms to put into Feff (ie use a large Rmax in Atoms), but limit the number of paths with a reduced Rmax in Feff. I used Artemis/Atoms to make up a Feff input file (feff.inp) from crystallographic parameters, setting Rmax in Atoms to a relatively large value of 7.5 Å to create quite a large cluster of atoms. I then used FEFF to calculate scattering paths within the cluster, but first reduced the Rmax in feff.inp to 5.5 Å to limit the number of paths. So far so good. I then (for reasons too involved to discuss here) edited the feff.inp file to delete all atoms more than 5.5 Å from the centre, and ran Feff again. The results (judging from the relative amplitude values) were different, and in the case of some paths very different. Some intense paths changed in amplitude by a factor of 2 or greater, although I haven't looked at the finer details of the Feff results. The paths that changed the most were high-order multiple scattering paths, and surprisingly those paths did not involve atoms at the edges of the 5.5 Å radius. Now I'm sure that someone else can explain the reasons for this much better than I can, but I assume that the potentials for the atoms outside the 5.5 Å radius (which were neglected in the second calculations) significantly affect those inside the radius. I know that its always been my practice to perform the Feff calculation using only those atoms that I think are contributing to my spectrum, and I'm sure that others do the same. My advice is to use a larger cluster of atoms in Feff if you can - but as to how large I might leave that to someone else to comment. Regards, Peter PS - and four cheers to Bruce for improvements to Artemis, I can't wait for the Windows update. Peter Southon Post Doctoral Fellow School of Chemistry University of Sydney NSW 2006, Australia +61 2 9351 4425

2 1

horae 034 Debian packages
by Carlo U. Segre 20 May '04

20 May '04

Packages of the new horae are available for the unstable and stable distributions of Debian at # stable deb http://fermi.phys.iit.edu/debian/woody binary/ deb-src http://fermi.phys.iit.edu/debian/woody source/ # unstable deb http://fermi.phys.iit.edu/debian/sid binary/ deb-src http://fermi.phys.iit.edu/debian/sid source/ Please contact me if you have any problems installing them. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 segre(a)agni.phys.iit.edu http://www.iit.edu/~segre

1 0

cloning feff calculations
by Bruce Ravel 20 May '04

20 May '04

Hi! Artemis now allows you to easily reuse entire feff calculations within a project. This is something you might want to do in a variety of situations. Here is one example: You have data at several temperatures. After spending some time working on your fitting model for a single data set and at one temperature, you decide to convert your project to a multiple data set, multiple temperature model. You would like to use the same feff calculation and all the same paths to fit each data set, changing only those parameters related to the changing temperature. This is now easy. In the Data menu is an option for "Clone a FEFF calculation". Here is how it works: 1. Select the data set for which you wish to use an already-defined feff calcultion. In my example, you would select the most recetly imported data set. 2. Choose the Clone option from the Data menu. This will pop up a dialog box listing all feff calculations used throughout the project. (If there is only one, it will be a short list!) 3. Choose a feff calculation and click OK. That calculation, all its paths, and all path parameters associated with the paths will be copied to the new data set. You may need to play around with it to see how it works. Once you see, it's quite simple: you select a data set and apply an existing feff calculation to the selected data set. There are two options for cloning a feff calculation. They are called "linking" and "copying". The difference between them is how the files from the feff calculation are handled. A linked clone points at the same set of files, a copied clone makes its own copies of all the files from the feff calculation. You should link when you want to be 100% sure that the exact same feffNNNN.dat files will be used each time the calculation is used. Also, the project file will be significantly smaller when you link compared to when you copy. You should copy if you think you might need to alter the feff calculation in one case separately from the other. Since this is a brand new feature, I suspect that people will find ways to break it. Let me know when that happens. 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/

1 0

the new GDS page
by Bruce Ravel 20 May '04

20 May '04

Hi! The biggest new feature of Artemis in today's release is the new page for setting the Guess, Def, and Set parameters. Here is a screenshot: http://leonardo.phys.washington.edu/~ravel/software/exafs/images/artemis/ar… The document has been updated to describe the new format of the GDS page. http://leonardo.phys.washington.edu/~ravel/software/exafs/doc/artemis.pdf See section 5.7.9. As you can see, the parameters are now displayed in a list structure rather than as a stack of entry boxes. This allows many more parameters to be displayed at one time in the same space. The new layout also allocates more horizontal space to the display of the math expressions. The different kinds of parameters are displayed according to their type. The color of the text and the content of the second column indicate the parameter type. Guess parameters are in purple text and have the "g:" tag in the second column. Set parameters are in black text and have the "s:" tag. Defs are green and have "d:". Skip parameters are grey and have no tag. Not shown in the screenshot are restrains, which are pink and have the "r:" tag in the second column. To edit a parameter, click on its entry in the list. This highlights that parameter in grey, as shown for the "fee0" parameter in the screenshot. The name, type, and math expression for that parameter are entered in the space at the bottom of the page and are ready to be edited. Click the "New" button to create a brand new parameter. The neatest new feaure is what I call parameter annotation. An annotation is a short text string which says something useful about the parameter. An example of this is seen in the screen shot. The selected parameter was annotated after the fit with its best fit value and error bar. Whenever you click on a parameter, its annotation is shown in the echo area. If you double-click on a parameter, you will be prompted to supply an annotation for that parameter. This provides a nice way of documenting the role each parameter plays in the fit. There are lots of other neat features of the new GDS page. For instance, Artemis does not allow you to define a parameter more than once. And there is a very useful context menu that gets posted when you right-click on a parameter. It may take a bit of getting used to, but I suspect that you will enjoy the new GDS page. I find it to be both more powerful and easier to use than the previous format. Enjoy, B P.S. Thanks go to Scott, who I hope does not mind that I used his project file for the screenshot. -- 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/

1 0

Starting out with Artemis 0.7.003
by m.bondin＠pgrad.unimelb.edu.au 18 May '04

18 May '04

Hi all - I am starting out with the latest release of Artemis on Win XP (thought I would give the new and improved version a go since I like the idea of incorporating atoms in the fitting interface). I read in my data file and atoms file, got my feff.inp then attempted to generate my feff paths - Artemis asked me to pick an option (first ten, all etc) and gave me a new window with no paths listed and the message "Artemis trapped a warning! Message dumped to C:\Program Files\Ifeffit\horae\ARTEMIS.TRAP" Is Atoms now able to claculate feff paths and display them within Artemis or does it not yet have this capability? Many thanks, -- Mark Bondin PhD student School of Chemistry, University of Melbourne

2 1

[HOWTO] converting experimental mu(E) in cm^-1
by mauro＠rulp.org 14 May '04

14 May '04

Hi, I would like your opinion on the procedure to convert the experimental mu_exp(E) in arbitrary units (counts) to mu(E) in cm^-1. This is my "student" procedure: 1. take mu_exp(E) - with EXAFS - spectrum in counts 2. take mu_th(E) - without EXAFS - spectrum in cm^-1 (from MacMaster or XOP software) 3. plot 1+2 4. while mu_exp(E) != mu_th(E) do (by hand!) 4a. mu(E) = A * mu_exp(E) + B When the two spectra coincide (more or less) I assume that the mu(E) is converted in cm^-1 units. Is this right? Does it already exist a software that makes this work automatically? Could be interesting to implement it in Athena? Thanks, M. -- Mauro Rovezzi <mauro(a)rulp.org> - Physics student University of Rome "Tor Vergata", ESRF Beamline BM8 - GILDA

4 8

RE: RE: [Ifeffit] graphics and fit
by Kelly, Shelly D. 13 May '04

13 May '04

Hi Mark and Jeff, Here is a copy of the program. I tried to document the script well. If you have trouble, let me know. You can e-mail me off of the list. skelly(a)anl.gov. Shelly > -----Original Message----- > From: Jensen, Mark P. > Sent: Thursday, May 13, 2004 1:33 PM > To: Kelly, Shelly D. > Subject: RE: [Ifeffit] graphics and fit > > > Shelly, > > I can see several metal-ligand complexes that I have looked > at recently where your program for manipulating groups of > atoms would probably have been very useful. If you really are > willing to share, I would sure appreciate having a chance to > try it out. > > Mark Jensen > > > ------------------------------ > Mark P. Jensen > Chemistry Division > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439-4831 > USA > 630-252-3670 > 630-252-7501 FAX > mjensen(a)anl.gov >

2 1

RE: [Ifeffit] graphics and fit
by Kelly, Shelly D. 13 May '04

13 May '04

Hi Stefano, Another free program that can read the output from atoms is ghemical. http://www.uku.fi/~thassine/ghemical/ I have written a rather specialized code that allows you to rotate a group of atoms until one of those atoms is at a determined distance from the original atom. Here let me explain for the specific example that I used it for. Say you have a Uranium atom and attached to it through an oxygen atom you have a PO4 group. One of the oxygen atoms of the PO4 group is shared with the uranium atom. Now from your exafs data you know that the U-P distance should be some number call it Rp. This program will leave the shared oxygen atom at the same spot, but move the PO3 atoms until the distance for U-P matches Rp. There are lots of ways that you can move the PO3 atom. The program is written to try to bend the PO3 group first and then translate the PO3 group to make the distance match. Then the program writes out the coordinates for all the atoms. This code is written in perl and doesn't have a gui interface, but I would be happy to share. Shelly > -----Original Message----- > From: Stefano Ciurli [mailto:stefano.ciurli@unibo.it] > Sent: Thursday, May 13, 2004 5:31 AM > To: XAFS Analysis using Ifeffit > Subject: [Ifeffit] graphics and fit > > > Hello, > > just a thought: wouldn't it be nice to be able to read the feff.inp > file directly into a simple molecular graphics program in order to > see if the used coordinates contain any error? Maybe it is possible > already and I am not aware of it. I understand that the program is > mainly used by material scientists, but for us working with > biological samples of metalloproteins it would be nice. > Another suggestion: I know that Excurve is able to treat the > histidine rings as a unity, and when performing the fit that program > is able to maintain the ring rigid while fitting the distance between > the metal and the imidazole ring of the histidine. How can I do that > simply using your suite? > > 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 > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listi> nfo/ifeffit >

3 2

Re: [Ifeffit] newcomer's simple trouble
by Stefano Ciurli 13 May '04

13 May '04

Problem solved! Textedit (the program I used this morning and that I thought was like vi, instead...) messes up the file format. Now I have a working feff.inp file and can start to work. Sorry for bothering. 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 2

newcomer's simple trouble
by Stefano Ciurli 12 May '04

12 May '04

Hello, this is a more intelligent input file which still gives the same error: Stefano TITLE Ni(H2O)6 HOLE 1 1.0 * Ni K edge (8333.0 eV), second number is S0^2 * mphase,mpath,mfeff,mchi CONTROL 1 1 1 1 PRINT 1 0 0 0 RMAX 6.0 POTENTIALS * ipot Z element 0 28 Ni 1 8 O ATOMS * this list contains 7 atoms * x y z ipot tag distance 0.00000 0.00000 0.00000 0 Ni1 0.00000 1.91860 0.00000 0.00000 1 O1_1 1.91860 0.00000 1.91860 0.00000 1 O1_1 1.91860 0.00000 0.00000 1.91860 1 O1_1 1.91860 -1.91860 0.00000 0.00000 1 O1_1 1.91860 0.00000 -1.91860 0.00000 1 O1_1 1.91860 0.00000 0.00000 -1.91860 1 O1_1 1.91860 END

2 2

status of self-absorption corrections
by mauro＠rulp.org 11 May '04

11 May '04

Hi to all, I would like to ask you which is the status of the discussion on the self-absorption corrections to fluorescence EXAFS. I'm working on Mo/Si multilayers, studied by standing-wave-assisted EXAFS. My data are collected at grazing incidence (phi + theta = 90 deg) with a Ge (13 elements) detector. I have done data analysis without self-absorption corrections and I have found good results, except for the amplitude (S_0^2) that is very low (~0.50). I think this low value is due to self-absorption, so I would like to demonstrate it. My dilemma is: Troger's approach or Booth's one? I personally think that Booth's (simple) approach, could be used in this particular case (Ge detector, phi+theta=90deg), but my tutor told me that I can't assume a neglectable solid angle for a Ge detector so I have to use the Troeger's (quite difficult) approach. >From the mailing-list archive, I have read your discussion about this topic but I haven't found something like a "conclusion". Is there anyone who use Booth's approach with good results? Have you already done "tests" of this method? Is it possible to improve it? Finally, what about the software status? Matt, have you done something on Booth's Fortran code? Thanks, Mauro -- Mauro Rovezzi <mauro(a)rulp.org> - Physics student University of Rome "Tor Vergata", ESRF Beamline BM8 - GILDA

2 2

[Ifeffit]
by Webb, Samuel M. 10 May '04

10 May '04

Aaron -- That worked perfectly. Thanks! (it is the system32 directory) The default windows one (although "newer") was 10k short of the one that is distributed with IFEFFIT. Sam >Sam, > I ran into this about a week before the APS Users Meeting. Right after I >upgraded to the newest version of Athena/Artemis/et al. I did find the >solution. Check in your system32 subdirectory (I think, it may be system) of >the windows directory. There could be a DFORRT.dll located there. The >DFORRT.dll file in that location was rather date, possibly from '99. This old >file was set in the windows path, and it was accessing it even though newer >versions were available. I found that replacing the old DFORRT.dll file with >the newer version fixed the problem. You might have to do a google search if >you don't have a newer version on your computer. If you can't find a newer >version of DFORRT.dll that works, I'll post the one that I am using up online. > > >Sorry guys, I guess I should have sent something to the list about this >immediately.. > >Aaron Stuckey

1 0

[Ifeffit]
by Webb, Samuel M. 10 May '04

10 May '04

Quick question for everyone about the behavior of the latest updates on WinXP with Athena and Artemis et al. I manually unzipped all the updates and ran into the following error (which is likely due to my own problems). When I click on the hephaestus.bat file (WinXP), I get "The procedure entry point _FIIfexp_ could not be located in the dynamic link library DFORRT.dll." in a dialog box, then everything closes. This is also the case for Artemis.bat and Athena.bat. My version of IFEFFIT that was not updated does not have this problem. Copying the former version of DFORRT.dll from my working installation does not appear to help either. Going thru the updates from the start, I found that this error arises in update 007 and 008, but not 006. The same behavior happens for me if I use the autoupdater, rather than manually installing the updates. Sixpack seems to be unaffected. Anyone have any idea or seen this before? Sam ******************************************** Sam Webb SSRL/SLAC Bldg. 137, MS 69 2575 Sand Hill Rd. Menlo Park, CA 94025 Phone: (650)-926-3734 FAX: (650)-926-4100 E-mail: samwebb(a)slac.stanford.edu *******************************************

4 3

Upgrade issues
by Webb, Samuel M. 10 May '04

10 May '04

>I've never heard of this, and don't know what FIIfexp might mean. >There wasn't much change between 006 and 007 -- certainly not to >DFORRT.dll or ifeffit_10.dll, so it seems pretty strange. It does >appear that the DFORRT.dll in ifeffit/sixpack/ is older than the one >in ifeffit/. I'd be surprised if that had an affect, but it's easy >enough to try both versions of the dll. There's also a MSVCRT.dll >that you could try moving away, so that the system one gets used. > >Does this problem happen with ifeffit.bat? One thing that did >change between 006 and 007 was that the perl-generated executables >got smaller by a factor of 2. This might suggest that the perl >codes depend more heavily on other dlls for code, but I don't know >any of the details... > >--Matt Well, after some more investigation, I can get the upgrades to work on just about every other computer on site except for mine. The .bats all look fine, as near as I can tell. As you suggested Matt, it only appears that the perl codes -- the ones that depend on IFEFFIT are problematic. The rest (such as ifeffit.bat and sixpack) seem fine. Even uninstalling everything and reinstalling doesn't seem to help at all. I guess I'll manage with the old versions for now. Thanks all! Sam

1 0