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

RE: [Ifeffit] Running FEFF
by Kelly, Shelly D. 11 Jun '04

11 Jun '04

Hi Poorani, I believe that Athena and Artemis do not work properly when installed in the C:/program files/ifeffit directory. The installation proceedures say to specify C:/ifeffit instead. To fix if, but all of C:/program files/ifeffit into the trash and then re-install. Shelly -----Original Message----- From: Ssk0016(a)aol.com [mailto:Ssk0016@aol.com] Sent: Thursday, June 10, 2004 9:55 PM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: [Ifeffit] Running FEFF Hello All, I"m a graduate student and trying to use Athena and Artemis for EXAFS analysis.I just follow the steps ,as mentioned in the manual,to do Cu example.this is what I did. * First I opened the Chi file * Then I imported the Atoms input file,and typed all the informations and pressed "run atoms". * It gave me Feffinput.Then I pressed "run Feff".Then the bar at the bottom of the screen blinked and in very short time it asked "how many paths I want",and I clicked the button. ....It supossed to give the message screen with all the details and then all the paths should be displayed at "data & Paths". But it didn't,insted the message screen was displayed with no messages.Also there was a warning at the bottom says "Message dumped to C:/program files/ifeffit/horae/stash/ARTEMIS.TRAP". So i went to file menu and clicked "import feff calculations" and import ARTEMIS.TRAP.then in the interpretation page ,there was a message screen saying "couldnot find feff.inp,files.dat,paths.dat". I don't know how to solve this problem.Can anyone help me to overcome this? NOTE: I'm using windows XP. thanks Poorani ' i opened th

1 0

Running FEFF
by Ssk0016＠aol.com 10 Jun '04

10 Jun '04

Hello All, I"m a graduate student and trying to use Athena and Artemis for EXAFS analysis.I just follow the steps ,as mentioned in the manual,to do Cu example.this is what I did. * First I opened the Chi file * Then I imported the Atoms input file,and typed all the informations and pressed "run atoms". * It gave me Feffinput.Then I pressed "run Feff".Then the bar at the bottom of the screen blinked and in very short time it asked "how many paths I want",and I clicked the button. ..It supossed to give the message screen with all the details and then all the paths should be displayed at "data & Paths". But it didn't,insted the message screen was displayed with no messages.Also there was a warning at the bottom says "Message dumped to C:/program files/ifeffit/horae/stash/ARTEMIS.TRAP". So i went to file menu and clicked "import feff calculations" and import ARTEMIS.TRAP.then in the interpretation page ,there was a message screen saying "couldnot find feff.inp,files.dat,paths.dat". I don't know how to solve this problem.Can anyone help me to overcome this? NOTE: I'm using windows XP. thanks Poorani ' i opened th

2 1

PCA
by ebrown＠slc.edu 10 Jun '04

10 Jun '04

I've just started doing EXAFS analysis and I have a few questions. I imported EXAFS data (prepared by Athena) into SixPack and ran a principle component analysis on the date. I then ran some target transforms of the dominant components targeting different compounds we thought could be part of the data. This has yielded some extremely useful indicators of which compounds are most likely in the sample. However, there's a limited amount of information available from the SixPack PCA. Is there any way to find out information about the makeup of components? The "Save Components" option doesn't work. Also, for the target transform feature: is there any way to find out how much of each component is used to make the transform? Presumably, this information would need to be calculated in order to make the transform in the first place, but I can't find any way to access that information. I've found SixPack very helpful, but if there's other PCA's that provide these features, that would also be useful. Thanks, Ethan Brown

1 0

trying to run artemis again
by doug pease 10 Jun '04

10 Jun '04

Thank you Carlo and Shelly, I think the warning message is that "rmax is greater than the distance to the most distant atom" . My cluster size I put into ATOMS the last time I ran this is 5.5. The message then says rmax,ratx 5.5000 5.09117. (My experimental data goes to R = 6.) No matter what cluster size I choose I get the same warning with ratx less than rmax by a small amount. I have tried several cluster sizes and always get the same warning. Sincerely, Doug

2 1

Re: [Ifeffit] more fun with FFTs
by Scott Calvin 10 Jun '04

10 Jun '04

Thanks to both Matt and Grant for clarifying several issues. You've given me a lot to chew on and inspired me to go back and take another close look at all of this. Hopefully I'll have more to add to this discussion once I do! --Scott Calvin Sarah Lawrence College >

1 0

more fun with FFTs
by Grant Bunker 09 Jun '04

09 Jun '04

....to clarify my earlier remarks... The experimental chi is the amplitude times the sine of the phase, and is of course a real number. However, if you determine the amplitude and phase, you do it by separating the real chi into two complex functions Amplitude*Sin(phase) = (Amplitude*(Exp(I phase) - Exp(- I phase))/(2 I) which have most of their spectral power at distinct locations in the r-space transform. This is done by k->r transform, zeroing one of terms, multiplying by 2I, and backtransforming r->k. The amplitude and phase are easily determined from the real and imaginary parts of the complex result. When using Fourier methods it is most useful to look at chi as the imaginary part of this "complex chi"= Amplitude Exp(I phase), and that was what I meant. It's just like saying the "scattering amplitude" F(k) and phase are two components of the complex scattering ampltude: scattering amplitude = |scattering amplitude| * Exp(I scattering phase). This mathematics is implicit in all of scattering theory and XAFS in particular. Regarding window effects, I think the most useful way to think about them is to realize the Fourier transform of windowed weighted chi is the convolution of the fourier transforms of the k-window and the unwindowed weighted chi (convolution theorem). What the window does is give an r-space transform that is the convolution of a scraggly function (~ sin(x)/x for a sharp k-space cutoff) with the nice peak you (probably) would have had if you had an infinite range of chi. The width of the r-space peaks and the structure of the side lobes is principally due to the fourier transform of the k-space window. If the k-window doesn't have sharp corners (like a box does) its fourier transform will be smoother and there will be less truncation ripple in r-space. That's why tapered windows are helpful. One is free to use arrays of other lengths, or to eschew zero padding altogether, but I don't think the transforms would be very useful at a quarter angstrom sampling, certainly not in the sense they normally are. thanks - grant On Wed, 9 Jun 2004 ifeffit-request(a)millenia.cars.aps.anl.gov wrote: > Send Ifeffit mailing list submissions to > ifeffit(a)millenia.cars.aps.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > or, via email, send a message with subject or body 'help' to > ifeffit-request(a)millenia.cars.aps.anl.gov > > You can reach the person managing the list at > ifeffit-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: E0 correction in EXAFS fitting (Matt Newville) > 2. more fun with FFT's (Grant Bunker) > 3. Re: more fun with FFT's (Scott Calvin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 Jun 2004 13:19:22 -0500 (CDT) > From: Matt Newville <newville(a)cars.uchicago.edu> > Subject: Re: [Ifeffit] E0 correction in EXAFS fitting > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: > <Pine.LNX.4.44.0406082306500.28025-100000(a)millenia.cars.aps.anl.gov> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Dear Wojciech, > > It seems like this question has been asked many times, possibly in > slightly different form. > > Feff's choice of E0 can be off by several eV. Also, Feff is not > good at distinguishing formal oxidation state. So believing > Feff's E0 may not be the best idea. In my experience, Feff tends > to pick an E0 that is relatively far up the main absorption edge, > generally several eV above the maximum of the first derivative. > That's consistent with the traditional lore that says the max of > the first derivative is the Fermi level, not E0 (lowest unoccupied > orbital). > > If athena/autobk pick E0 to be on a sharp pre-edge peak, you > probably want to move it. But the best placement for E0 is not > easy to make when there is a large pre-edge peak. > > One camp says that since there is absorption, then it's at E_0, > and the pre-edge peak is really the absorption edge, followed by a > large negative EXAFS 'black line' oscillation that nearly sends > mu(E) to zero. The other camp invokes localized states (either > excitons or empty molecular orbitals) to say the pre-edge peaks > are really quasi-bound transitions, but below the real continuum. > I'll try to avoid that debate. > > I couldn't tell whether there was a large pre-edge peak followed > by the main absorption edge or a very large white line. If I > understand, it sounds like Feff is trying to put E0 at the > pre-edge peak... is that correct? > > I'm sure that leaves unanswered questions, but I hope it helps > show the general level of confusion about E0. > > --Matt > > On Tue, 8 Jun 2004, it was written: > > > Dear Bruce and other mailing list users, > > > > I have a very basic question concerning the choice of E0 in EXAFS data > > analysis. Recently I have been working on Ru solvated complex. I don?t > > go into too many details but I can say it?s a pretty large molecule in > > aqueous solution with 3 ligands containing 6 N atoms and 30 C atoms in > > D3 symmetry. Now, we have measured the L3 edge XANES and EXAFS of this > > molecule and I have recently tried to analyze it. Now, what bothers me a > > lot is the following observation: once I start processing the data > > (meaning background removal, pre-edge subtraction etc.) AUTOBK in both > > Ifeffit and Athena ?proposes? to place the edge energy E0 at the > > inflection point of the spectrum which lies at about 2838-2839 eV (which > > corresponds to atomic Ru L3 edge absorption energy). You might say it?s > > ok but I cannot accept this value. The inflection point lies on a huge > > pre-edge peak which is the 4d bound-to-bound transition (white line) > > which in principle I don?t want to include in my chi(k) because it?s > > still below the ionization energy as I understand it. I guess the > > continuum states should start higher in energy and actually from other > > spectroscopies one would suspect the E0 to be around 2847 eV (so about > > 7-8 eV higher in energy space). Now I set my E0 to this value and I > > started fitting the spectrum with FEFF calculation performed on > > crystalline structure of the same complex. What I end up with is always > > E0 correction for the first shell of neighbors (meaning N atoms) between > > -6 to -7.5 eV. I check in chi.dat and xmu.dat files that in my FEFF > > calculation the k=0 value was assigned to approx. 2839 eV so it?s the > > same atomic value again. However I know it shouldn?t be like that (apart > > from a simple fact that Ru in my compound is in its 2+ oxidation state > > which surely moves the E0 toward higher energies, doesn?t it?). So, I > > tried to fool FEFF and make some tricks like shift my data in energy > > space or fit the white line and subtract it form the data but it always > > consistently converges to place the E0 value at the first inflection > > point meaning between 2839-2842 eV. I thought that when fitting the > > experimental data with FEFF scattering paths one can choose E0 and then > > refine its value by shifting the FEFF-calculated E0 by the amount which > > comes out of the fit. So if I have some value of E0 coming out of my fit > > then I just shift the initial k=0 value as estimated by FEFF using k? -> > > sqrt( k-E0(2m/h_bar^2) ) (in other words the negative E0 correction > > would always shift the origin in k-space towards larger k values which > > means lower values in energy space). Ok, so now my question is the > > following: is there an explicit way to set E0 value before letting FEFF > > to do its job or it will always use the tabulated atomic value? So, if I > > don?t know my E0 a priori how can I refine it for a complex or molecule > > which has different oxidation state than 0? I mean it?s a serious > > question in my opinion and I wish I could get some feedback from people > > who have been doing it for so many years. > > I hope I made my point clear enough to you. Let me know if you need any > > more feedback in order to answer my question. I?ll be glad to give more > > details. > > Best regards, > > > > 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 > > ********************************************************************* > > > >

1 0

need more help with artemis
by doug pease 09 Jun '04

09 Jun '04

Hi, I tried Mary Shelly's suggestion to increase the resolution for my Windows XP monitor and this worked. Now I can run ATOMS from Artemis. Now the following happens: Running simple copper metal I generate an input file for FEFF that looks o.k. to me. I run FEFF and it generates paths that make sense....12 near neighbors of the right distance and so on. The Cu CHI function data is imported o.k. and a FT is displayed that looks fine. But the expected path input dialog box never comes up. According to the manual, once I start FEFF this dialog box is supposed to pop up asking how many paths I want to import and THEN FEFF is supposed to compute. The dialog box step is skipped. It says "message dumped to ENV-IFEFFIT-DIR-\HORAE\STASH\ARTEMIS.TRAP" I don't know where to look for this message , or why the dialog box never shows up. Any suggestions? Sincerely, Doug Pease

2 1

Re: [Ifeffit] more fun with FFT's
by Scott Calvin 09 Jun '04

09 Jun '04

Thanks to Matt and Grant for the comments. After reading Grant's comments, it appears I have some significant gaps in my understanding of some basic EXAFS concepts: Chi(k) is complex? That's a completely new concept to me. I thought chi(R) was complex because a complex Fourier transform was used, and that chi(k) was real. After all, the peaks of chi(k) correspond to peaks in the energy spectrum...if that is the real part of chi(k), what does the imaginary part correspond to? I still disagree with the assertion that you always have truncation effects when using a finite k-range. As I understand the properties of Fourier transforms, using a finite range is identical to using an infinite range with a periodic function that repeats the pattern seen in the finite range over and over. So if it happens that the function at the end of the range connects smoothly with the function at the beginning of the range, there should be no truncation effects. This can also be looked at another way. In terms of the sinc function due to the finite range, the zeroes of the sinc function correspond exactly with the points in r-space at which the Fourier transform is evaluated, and thus the Foruier transform is only non-zero at one point. I have simulations that show this, but if I missed that chi(k) was complex, that could mean there is an error in this logic. As I understand Grant's comments, you can show that the sinc function is "really" still there by padding with zeroes, thus improving the resolution in r-space, and revealing the side-band structure. I agree that this is what will be observed, but if I consider this from the point of view of a FT of a finite range being the same as the FT of an infinite function which repeats the finite section periodically, then the zero-padding is introducing discontinuities which were not previously there. It is, I think, a matter of semantics whether one considers the side-bands to be "really" there when the FT is not evaluated at values of r where it is non-zero. But in either way of looking at it, padding with zeroes introduces non-zero values to the discrete FT outside of a region where there were only zero values before. None of this is meant in any way as a criticism of the algorithm used by Ifeffit as Matt described it. Windowing and then padding with zeroes makes the truncation effects relatively consistent...if there is a downside to forcing chi(k) to go to zero at the endpoints, so be it, but this strategy means the downside is always present. Alternative strategies which encourage picking whole periods of chi(k) for the data range, for example, risk being self-fulfilling, so that the period chosen for the data range might be emphasized in the Fourier transform at the expense of other spectral frequencies. To sum up, I am now very curious as to whether there is some sense in which chi(k) is complex. If that's true, I'll have to rethink a lot of my understanding as to how this all fits together. --Scott Calvin Sarah Lawrence College At 02:26 PM 6/9/2004 -0500, Grant wrote: >This is in response to Scott's remarks about zero padding and windows. >The basic point is that you *always* have fourier truncation effects if >you are using a finite k range. If you Fourier transform a pure sine wave >over a finite range you will get side lobes that go like |sin(x)/x|. This >is true whether you zero pad or not. You won't be able to resolve the side >lobe structure if you don't zero-pad however. All you will see is a single >point. A useful way to think about it is to view the discrete FFT as a sampled >version of the continuous transform (side lobes and all) where the r-space >sampling is controlled by size N of the zero padded array (and dk). >Hhe zero padding doesn't change the window distortions, it just allows you >to see them better. > >You can of course mitigate the side lobes by applying a k-window to taper >the amplitude down to zero at the cutoff, but at the expense of broadening the >central part of the peaks. > >There also is a common myth that if you choose the cutoff to be where >chi is zero anyway, that you don't get fourier truncation effects. This is >not true. Even if chi (Amplitude*sin(phase)) is zero at a particular k >value the amplitude may not be. Imagine a thought experiment in which >you shift the phase of chi by a Pi/2, so a node becomes an antinode. >Mathematically this is the same as multiplying the complex chi >A exp(i phi) by exp(i Pi/2). Since the fourier transform is linear, the >filtered (transformed, r-windowed, and inverse transformed) data are just >shifted in phase by Pi/2. The fourier filtering distortions are precisely >the same when you cut at a node or an antinode. > >I'll try to dig up some simulations I did many moons ago and post >them. >>>

2 1

more fun with FFT's
by Grant Bunker 09 Jun '04

09 Jun '04

This is in response to Scott's remarks about zero padding and windows. The basic point is that you *always* have fourier truncation effects if you are using a finite k range. If you Fourier transform a pure sine wave over a finite range you will get side lobes that go like |sin(x)/x|. This is true whether you zero pad or not. You won't be able to resolve the side lobe structure if you don't zero-pad however. All you will see is a single point. A useful way to think about it is to view the discrete FFT as a sampled version of the continuous transform (side lobes and all) where the r-space sampling is controlled by size N of the zero padded array (and dk). Hhe zero padding doesn't change the window distortions, it just allows you to see them better. You can of course mitigate the side lobes by applying a k-window to taper the amplitude down to zero at the cutoff, but at the expense of broadening the central part of the peaks. There also is a common myth that if you choose the cutoff to be where chi is zero anyway, that you don't get fourier truncation effects. This is not true. Even if chi (Amplitude*sin(phase)) is zero at a particular k value the amplitude may not be. Imagine a thought experiment in which you shift the phase of chi by a Pi/2, so a node becomes an antinode. Mathematically this is the same as multiplying the complex chi A exp(i phi) by exp(i Pi/2). Since the fourier transform is linear, the filtered (transformed, r-windowed, and inverse transformed) data are just shifted in phase by Pi/2. The fourier filtering distortions are precisely the same when you cut at a node or an antinode. I'll try to dig up some simulations I did many moons ago and post them. grant On Tue, 8 Jun 2004 ifeffit-request(a)millenia.cars.aps.anl.gov wrote: > Send Ifeffit mailing list submissions to > ifeffit(a)millenia.cars.aps.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > or, via email, send a message with subject or body 'help' to > ifeffit-request(a)millenia.cars.aps.anl.gov > > You can reach the person managing the list at > ifeffit-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. more fun with FFTs (Grant Bunker) > 2. E0 correction in EXAFS fitting (Wojciech Gawelda) > 3. Re: more fun with FFTs (Scott Calvin) > 4. beginning with ARTEMIS (doug pease) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 8 Jun 2004 12:34:58 -0500 (CDT) > From: Grant Bunker <bunker(a)biocat1.phys.iit.edu> > Subject: [Ifeffit] more fun with FFTs > To: ifeffit(a)millenia.cars.aps.anl.gov > Message-ID: > <Pine.LNX.4.44.0406081222050.25188-100000(a)biocat1.phys.iit.edu> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Just to amplify Matt's remarks - the purpose of padding with zeros is to > deliver a finer grid in r-space. There is a relationship between the > r-space grid dr, the k-space grid dk, and the number of points in the > array (N): N dk dR = Pi. So, for a k-space grid of .05/A and 2048 > points, you get an r-grid spacing of .0307 A. This gives pretty good > sampling of the fourier transform. If you only use say 256 points in your > array (i.e. you don't pad with zeroes) the r-space sampling is .245 A, > which is too coarse to be useful. > > You might ask whether zero padding botches up the data. It can be shown > (I worked it out once) that zero padding is exactly equivalent to > an interpolation of the unpadded data witha specific interpolation kernel > (a sinc function or something as I recall). What happens is that as you > pad with more zeros into a longer array, the sampling in r-space increases, > and ultimately the curve looks just like what you would get with a continuous > fourier transform (with cutoff effects from the finite k-space window). > > grant > > On Tue, 8 Jun 2004 ifeffit-request(a)millenia.cars.aps.anl.gov wrote: > > > Send Ifeffit mailing list submissions to > > ifeffit(a)millenia.cars.aps.anl.gov > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > or, via email, send a message with subject or body 'help' to > > ifeffit-request(a)millenia.cars.aps.anl.gov > > > > You can reach the person managing the list at > > ifeffit-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: FFT in Ifeffit (Matt Newville) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 7 Jun 2004 22:55:28 -0500 (CDT) > > From: Matt Newville <newville(a)cars.uchicago.edu> > > Subject: Re: [Ifeffit] FFT in Ifeffit > > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > > Message-ID: <Pine.LNX.4.44.0406072214290.13810-100000@corvette> > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > > Hi Scott, > > > > All Fourier transforms in Ifeffit use arrays of length 2048, > > padding with zeros as needed. > > > > In earlier versions of Feffit, doing repeated FTs in the fitting > > loop was noticeably slow. This is probably one of the reasons > > fitting in R-space was uncommon. Anyway, using arrays of length > > N_fft = 1024, 512, or 256 definitely helped speed things up. > > > > In principle, one could use N_fft ~= N_idp, but it turns out that > > if you use too few FT points, you can easily get into a real > > 'false, local, minima'. So Feffit used 1024,512,or 256 for fits, > > and then go back to 2048 to write out the data. Strictly speaking, > > the FFT doesn't need to use an array size that is a power of 2, > > but it turns out to make a very noticeable difference with the FFT > > routines used. > > > > With Ifeffit, several "anti-optimizations" were made that make > > the fits slightly slower but be more straightforward and simple > > (relatively speaking, anyway!). The use of double precision and > > N_fft=2048 being the main examples. Part of the reason for > > sticking with 2048 is that you want to be able to view the data at > > any point in the process so 'pretty output' is always needed. > > Also, I doubt many people will be trying to run artemis on a 386 > > or a microVAX. > > > > --Matt > > > > > As I was working on my talk for the EXAFS workshop, I came across a > > > rather technical question: how does Ifeffit choose the number of > > > points for the Fourier transforms? As I recall, FEFFIT used an > > > algorithm which required an integer power of 2, so its default > > > behavior was to use the smallest integer power of 2 greater than the > > > number of points in the chi(k) data, and then pad the rest with 0's. > > > This default behavior could also be over-ridden if desired. > > > > > > It doesn't look to me like Ifeffit is handling that in the same > > > way--is it always using a very large number of points and padding > > > with 0's, or is it using an algorithm that doesn't require the > > > integer power of 2, or is it interpolating the chi(k) on to a grid of > > > the appropriate size first, or...? > > > > > > I appreciate any info you can give me on this. > > > > > > --Scott Calvin > > > Sarah Lawrence College > > > _______________________________________________ > > > Ifeffit mailing list > > > Ifeffit(a)millenia.cars.aps.anl.gov > > > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > > > > > > > > > ------------------------------ > > > > _______________________________________________ > > Ifeffit mailing list > > Ifeffit(a)millenia.cars.aps.anl.gov > > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > > > > End of Ifeffit Digest, Vol 16, Issue 7 > > ************************************** > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 8 Jun 2004 20:04:25 +0200 > From: "Wojciech Gawelda" <wojciech.gawelda(a)epfl.ch> > Subject: [Ifeffit] E0 correction in EXAFS fitting > To: <ravel(a)phys.washington.edu> > Cc: ifeffit(a)millenia.cars.aps.anl.gov > Message-ID: > <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA+oqSCNd0OEmvPV/OsrrrucKAAAAQAAAAqvlml9Ymw0KfPXsmOeouUQEAAAAA(a)epfl.ch> > > Content-Type: text/plain; charset="iso-8859-1" > > Dear Bruce and other mailing list users, > > I have a very basic question concerning the choice of E0 in EXAFS data > analysis. Recently I have been working on Ru solvated complex. I dont > go into too many details but I can say its a pretty large molecule in > aqueous solution with 3 ligands containing 6 N atoms and 30 C atoms in > D3 symmetry. Now, we have measured the L3 edge XANES and EXAFS of this > molecule and I have recently tried to analyze it. Now, what bothers me a > lot is the following observation: once I start processing the data > (meaning background removal, pre-edge subtraction etc.) AUTOBK in both > Ifeffit and Athena proposes to place the edge energy E0 at the > inflection point of the spectrum which lies at about 2838-2839 eV (which > corresponds to atomic Ru L3 edge absorption energy). You might say its > ok but I cannot accept this value. The inflection point lies on a huge > pre-edge peak which is the 4d bound-to-bound transition (white line) > which in principle I dont want to include in my chi(k) because its > still below the ionization energy as I understand it. I guess the > continuum states should start higher in energy and actually from other > spectroscopies one would suspect the E0 to be around 2847 eV (so about > 7-8 eV higher in energy space). Now I set my E0 to this value and I > started fitting the spectrum with FEFF calculation performed on > crystalline structure of the same complex. What I end up with is always > E0 correction for the first shell of neighbors (meaning N atoms) between > -6 to -7.5 eV. I check in chi.dat and xmu.dat files that in my FEFF > calculation the k=0 value was assigned to approx. 2839 eV so its the > same atomic value again. However I know it shouldnt be like that (apart > from a simple fact that Ru in my compound is in its 2+ oxidation state > which surely moves the E0 toward higher energies, doesnt it?). So, I > tried to fool FEFF and make some tricks like shift my data in energy > space or fit the white line and subtract it form the data but it always > consistently converges to place the E0 value at the first inflection > point meaning between 2839-2842 eV. I thought that when fitting the > experimental data with FEFF scattering paths one can choose E0 and then > refine its value by shifting the FEFF-calculated E0 by the amount which > comes out of the fit. So if I have some value of E0 coming out of my fit > then I just shift the initial k=0 value as estimated by FEFF using k -> > sqrt( k-E0(2m/h_bar^2) ) (in other words the negative E0 correction > would always shift the origin in k-space towards larger k values which > means lower values in energy space). Ok, so now my question is the > following: is there an explicit way to set E0 value before letting FEFF > to do its job or it will always use the tabulated atomic value? So, if I > dont know my E0 a priori how can I refine it for a complex or molecule > which has different oxidation state than 0? I mean its a serious > question in my opinion and I wish I could get some feedback from people > who have been doing it for so many years. > I hope I made my point clear enough to you. Let me know if you need any > more feedback in order to answer my question. Ill be glad to give more > details. > Best regards, > > 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 > ********************************************************************* > >

1 0

E0 correction in EXAFS fitting
by Wojciech Gawelda 09 Jun '04

09 Jun '04

Dear Bruce and other mailing list users, I have a very basic question concerning the choice of E0 in EXAFS data analysis. Recently I have been working on Ru solvated complex. I dont go into too many details but I can say its a pretty large molecule in aqueous solution with 3 ligands containing 6 N atoms and 30 C atoms in D3 symmetry. Now, we have measured the L3 edge XANES and EXAFS of this molecule and I have recently tried to analyze it. Now, what bothers me a lot is the following observation: once I start processing the data (meaning background removal, pre-edge subtraction etc.) AUTOBK in both Ifeffit and Athena proposes to place the edge energy E0 at the inflection point of the spectrum which lies at about 2838-2839 eV (which corresponds to atomic Ru L3 edge absorption energy). You might say its ok but I cannot accept this value. The inflection point lies on a huge pre-edge peak which is the 4d bound-to-bound transition (white line) which in principle I dont want to include in my chi(k) because its still below the ionization energy as I understand it. I guess the continuum states should start higher in energy and actually from other spectroscopies one would suspect the E0 to be around 2847 eV (so about 7-8 eV higher in energy space). Now I set my E0 to this value and I started fitting the spectrum with FEFF calculation performed on crystalline structure of the same complex. What I end up with is always E0 correction for the first shell of neighbors (meaning N atoms) between -6 to -7.5 eV. I check in chi.dat and xmu.dat files that in my FEFF calculation the k=0 value was assigned to approx. 2839 eV so its the same atomic value again. However I know it shouldnt be like that (apart from a simple fact that Ru in my compound is in its 2+ oxidation state which surely moves the E0 toward higher energies, doesnt it?). So, I tried to fool FEFF and make some tricks like shift my data in energy space or fit the white line and subtract it form the data but it always consistently converges to place the E0 value at the first inflection point meaning between 2839-2842 eV. I thought that when fitting the experimental data with FEFF scattering paths one can choose E0 and then refine its value by shifting the FEFF-calculated E0 by the amount which comes out of the fit. So if I have some value of E0 coming out of my fit then I just shift the initial k=0 value as estimated by FEFF using k -> sqrt( k-E0(2m/h_bar^2) ) (in other words the negative E0 correction would always shift the origin in k-space towards larger k values which means lower values in energy space). Ok, so now my question is the following: is there an explicit way to set E0 value before letting FEFF to do its job or it will always use the tabulated atomic value? So, if I dont know my E0 a priori how can I refine it for a complex or molecule which has different oxidation state than 0? I mean its a serious question in my opinion and I wish I could get some feedback from people who have been doing it for so many years. I hope I made my point clear enough to you. Let me know if you need any more feedback in order to answer my question. Ill be glad to give more details. Best regards, 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 *********************************************************************

2 1

starting artemis
by doug pease 09 Jun '04

09 Jun '04

Hello All, My oversight not specifying the platform. When the ATOMS in ARTEMIS fills up the whole screen and the run button is off screen I am in Windows XP. I also have a - perhaps non standard - ViewSonic flat screen monitor, for what that is worth. Carlo, thank you for your interest. Do you or anyone else have a suggestion? Overnight I thought of perhaps trying to change my monitor settings to shrink my monitor display?? Sincerely, Doug Pease

2 1

RE: [Ifeffit] starting artemis
by Kelly, Shelly D. 09 Jun '04

09 Jun '04

-----Original Message----- From: doug pease [mailto:dougpease@comcast.net] Sent: Wednesday, June 09, 2004 6:57 AM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: [Ifeffit] starting artemis Hello All, My oversight not specifying the platform. When the ATOMS in ARTEMIS fills up the whole screen and the run button is off screen I am in Windows XP. I also have a - perhaps non standard - ViewSonic flat screen monitor, for what that is worth. Carlo, thank you for your interest. Do you or anyone else have a suggestion? Overnight I thought of perhaps trying to change my monitor settings to shrink my monitor display?? Sincerely, Doug Pease Hi Doug, If you can, you should increase the resolution of the display. On a win2k machine you go to the control panel and choose the Display icon. >From there you can increase the resolution by going to the setting tab and increase the screen area to be 1280 by 1024 pixels. (-I think that winXP should be similar.:) Shelly

1 0

beginning with ARTEMIS
by doug pease 08 Jun '04

08 Jun '04

Hello All, Just starting ARTEMIS for first time. Seems o.k. until I come to the place where I am to run ATOMS in ARTEMIS. The ATOMS view in ARTEMIS takes up the whole monitor screen and the button for running ATOMS is out of site. I cannot drag the view high enough to reveal the ATOMS run button. Any suggestions? Sincerely, Doug Pease

2 1

Re: [Ifeffit] more fun with FFTs
by Scott Calvin 08 Jun '04

08 Jun '04

First of all, thanks to Matt for the info--this seems to me to be a very sensible way for Ifeffit to handle the issue. In terms of Grant's comments, the interesting part to me (and I admit I am getting esoteric here) is that zero-padding has the potential to change the cutoff effects in some circumstances. If you're using a window that goes to zero anyway, then I think it has exactly the effect that Grant describes. But not all windows do this. As a particularly simple example, consider a perfect cosine function over an integer number of periods, with no window. Even though the transform is applied to a finite interval, the result is a spike to within the resolution discussed in Grant's post. (As I recall, the finite sampling also causes the transform to be periodic, but the period is large enough to be disregarded in EXAFS analysis.) But now consider the identical function over the identical interval with zero-padding. This introduces a sharp discontinuity, and causes lots of sidebands on the Fourier transform. Of course, I chose a very special case. Windows reduce this effect considerably, so I would certainly agree that zero-padding does not "botch up" the data. But I wonder if some reduction in sidebands could be achieved by, for example, using a window that goes to the average of the values of the function at the two ends of the interval rather than to 0 (and adjusting the windowing function accordingly). It's on my list of things to try when I get the chance...I don't expect it will make a dramatic difference, but it might make an incremental one. --Scott Calvin Sarah Lawrence College At 12:34 PM 6/8/2004 -0500, Grant wrote: >You might ask whether zero padding botches up the data. It can be shown >(I worked it out once) that zero padding is exactly equivalent to >an interpolation of the unpadded data witha specific interpolation kernel >(a sinc function or something as I recall). What happens is that as you >pad with more zeros into a longer array, the sampling in r-space increases, >and ultimately the curve looks just like what you would get with a continuous >fourier transform (with cutoff effects from the finite k-space window). >

1 0

more fun with FFTs
by Grant Bunker 08 Jun '04

08 Jun '04

Just to amplify Matt's remarks - the purpose of padding with zeros is to deliver a finer grid in r-space. There is a relationship between the r-space grid dr, the k-space grid dk, and the number of points in the array (N): N dk dR = Pi. So, for a k-space grid of .05/A and 2048 points, you get an r-grid spacing of .0307 A. This gives pretty good sampling of the fourier transform. If you only use say 256 points in your array (i.e. you don't pad with zeroes) the r-space sampling is .245 A, which is too coarse to be useful. You might ask whether zero padding botches up the data. It can be shown (I worked it out once) that zero padding is exactly equivalent to an interpolation of the unpadded data witha specific interpolation kernel (a sinc function or something as I recall). What happens is that as you pad with more zeros into a longer array, the sampling in r-space increases, and ultimately the curve looks just like what you would get with a continuous fourier transform (with cutoff effects from the finite k-space window). grant On Tue, 8 Jun 2004 ifeffit-request(a)millenia.cars.aps.anl.gov wrote: > Send Ifeffit mailing list submissions to > ifeffit(a)millenia.cars.aps.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > or, via email, send a message with subject or body 'help' to > ifeffit-request(a)millenia.cars.aps.anl.gov > > You can reach the person managing the list at > ifeffit-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: FFT in Ifeffit (Matt Newville) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Jun 2004 22:55:28 -0500 (CDT) > From: Matt Newville <newville(a)cars.uchicago.edu> > Subject: Re: [Ifeffit] FFT in Ifeffit > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: <Pine.LNX.4.44.0406072214290.13810-100000@corvette> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Hi Scott, > > All Fourier transforms in Ifeffit use arrays of length 2048, > padding with zeros as needed. > > In earlier versions of Feffit, doing repeated FTs in the fitting > loop was noticeably slow. This is probably one of the reasons > fitting in R-space was uncommon. Anyway, using arrays of length > N_fft = 1024, 512, or 256 definitely helped speed things up. > > In principle, one could use N_fft ~= N_idp, but it turns out that > if you use too few FT points, you can easily get into a real > 'false, local, minima'. So Feffit used 1024,512,or 256 for fits, > and then go back to 2048 to write out the data. Strictly speaking, > the FFT doesn't need to use an array size that is a power of 2, > but it turns out to make a very noticeable difference with the FFT > routines used. > > With Ifeffit, several "anti-optimizations" were made that make > the fits slightly slower but be more straightforward and simple > (relatively speaking, anyway!). The use of double precision and > N_fft=2048 being the main examples. Part of the reason for > sticking with 2048 is that you want to be able to view the data at > any point in the process so 'pretty output' is always needed. > Also, I doubt many people will be trying to run artemis on a 386 > or a microVAX. > > --Matt > > > As I was working on my talk for the EXAFS workshop, I came across a > > rather technical question: how does Ifeffit choose the number of > > points for the Fourier transforms? As I recall, FEFFIT used an > > algorithm which required an integer power of 2, so its default > > behavior was to use the smallest integer power of 2 greater than the > > number of points in the chi(k) data, and then pad the rest with 0's. > > This default behavior could also be over-ridden if desired. > > > > It doesn't look to me like Ifeffit is handling that in the same > > way--is it always using a very large number of points and padding > > with 0's, or is it using an algorithm that doesn't require the > > integer power of 2, or is it interpolating the chi(k) on to a grid of > > the appropriate size first, or...? > > > > I appreciate any info you can give me on this. > > > > --Scott Calvin > > Sarah Lawrence College > > _______________________________________________ > > Ifeffit mailing list > > Ifeffit(a)millenia.cars.aps.anl.gov > > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > > > > ------------------------------ > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest, Vol 16, Issue 7 > ************************************** >

1 0

Re: [Ifeffit] Using more than one E0
by Scott Calvin 07 Jun '04

07 Jun '04

Hi Wojciech, I have another suggestion. It is my secret, completely untested belief (which I am now revealing to everyone on this mailing list!), that some of the cases of "successful" fits using multiple E0's are masking problems caused by not considering a third cumulant. For those who may not know the role of this parameter, it in essence measures asymmetry in the distribution associated with a path. For example, if a pair of atoms are more likely to separated by a distance considerably larger than the mean separation than by a distance considerably smaller than the mean separation, then the third cumulant is positive. (The mathematical definition is that the third cumulant is the mean cube of the difference from the mean, in the same sense that sigma2 is the mean square of the difference from the mean.) In most cases, the third cumulant is small. Nevertheless, if it were 0 in all cases, then materials would not show any expansion with temperature! Through symmetry arguments, it is pretty clear that the third cumulant is most likely to be significantly nonzero for nearest-neighbor paths. What does this have to do with fitting different E0's? E0 and the third cumulant both affect the phase of the EXAFS signal, although they are weighted in different ways by k. Nevertheless, if a nonzero nearest-neighbor third cumulant is called for, allowing a different E0 for the nearest-neighbor instead would probably also improve the fit statistically. In this case, however, while the use of a third cumulant can be justified on physical grounds relatively easily, the use of a separate E0 is an arbitrary non-physical attempt to improve the statistics. So as far as I am concerned, I am more inclined, if my fit is not quite working out, to try allowing the third cumulant for paths in the first coordination shell to vary than I am to introduce multiple E0's. In fact, I usually do this at some point during the fitting process even if my fit is behaving fairly well to reassure myself that the third cumulant is 0 to within the uncertainty of the fit, and that constraining it to 0 is not distorting the values of the parameters I am interested it. Take all of this with a grain of salt; I wrote my dissertation on the third cumulant, and, to paraphrase Bruce, since I've spent a lot of time making a nice hammer, everything tends to look like a nail... --Scott Calvin Sarah Lawrence College > >I would like to address a couple of questions which are partially >related to my recent struggles in fitting some EXAFS data. I'm >trying to fit my data using several shells of different neighbors >including a few single scattering paths and also so multiple >scattering contributions (mainly collinear multiple scattering >paths) all calculated with the help of FEFF 8.20. Now, I found once >in the FEFFIT manual the following suggestion: one might consider >using several different E0's for different paths in order to improve >the fit. Ok, the explanation was based on some approximations coming >from FEFF code which include incomplete core-hole shielding, lack of >angular variations of the valence charge distribution and charge >transfer between atoms in polar materials. >My question is the following: does anyone of you have some >experience with such procedure? And if yes, shall than distinguish >between the first shell of nearest neighbors and the rest of the >atoms in terms of their E0 corrections (using 2 parameters)? Or >perhaps one can use separate E0's for each path?

3 6

trouble with Atoms on Mac OSX
by Michel Jaouen 04 Jun '04

04 Jun '04

Hi folks, I'm using a PM (2X1.8 MHz processors) under OSX v 10.3.4 (Panther latest version). I have installed ifeffit-1.2.5a two weeks ago and used Atoms many times since. It works well till yesterday when I loose the ability to use the space group browser with an error reported on the herre attached file. It looks that I have a problem with Tk, but I don't understand why. I have tried to make a new install from scratch after putting in the trash the ifeffit and perl (the one I assume to be put by the iffit installer in the home/lib folder): it didn't fix the problem. I found rather puzzling to find several perl folders (one coming from ifeffit and one from Fink). Looking my environnement, I found the following: PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin. I therefore modify my profile making a setenv to force to use the perl from ifeffit without any change. So it seems some hidden file is responsible of this behavior. I must say that if I enter the space group by hand, Atoms runs (e.g. it creates the feff.inp file). If anybody has a solution, I will appreciate. Additional point: I have compliled feff7 using the GNU g77 from Fink, but it stops the run with a segmentation fault. Any hint? Best regards Michel -- __________________________________________ Michel Jaouen Universite de Poitiers - UFR Sciences - SP2MI LMP UMR 6630-CNRS Boulevard Pierre et Marie Curie - Teleport 2 BP 30179 86962 Futuroscope - Chasseneuil Cedex France Tel : (33) 5 49 49 67 37 Fax : (33) 5 49 49 66 92 e-mail : Michel.Jaouen(a)univ-poitiers.fr __________________________________________

3 2

Debian packages
by Carlo U. Segre 04 Jun '04

04 Jun '04

Hello All: I have now packaged the latest horae (036) for Debian stable and unstable. There was a problem in previous versions for stable which I just now figured out how to fix and it involved making a back port of a newer perl module for the archiving/zipping of the project files. Sorry if this caused anyone problems. 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 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre

2 1

trouble with Tk on Mac OSX
by Michel Jaouen 03 Jun '04

03 Jun '04

Hi folks, I think somethings is broken with Tk. As reported in my previous e-mail I found a problem (I have not before 1st june!) with the space group browser of Atoms. In fact I have the same error with Artemis when pressing the fit button! The following message was trapped by Artemis: Artemiswarn/Users/mjaouen/.horae/stash/ARTEMIS.TRAPCODE(0x1e18a84) at /Applications/Ifeffit/bin/artemis line 1491 main::__ANON__('Tk::Error: unknown option "background" at /Library/Perl/ 5.8.1...') called at blib/lib/Tk.pm (autosplit into blib/lib/auto/Tk/Error.al) l ine 488 Tk::Error('MainWindow=HASH(0x61e5d8)','unknown option "background" at /Library/Perl/5.8.1/darwin-thr...','Tk callback for .sgb.frame','Tk callback for . sgb.frame.ysbslice','Tk callback for .sgb.frame.ysbslice.corner','Tk callback for ..sgb','Tk callback for .sgb.button1','Tk callback for .frame.menubutton5.menu', 'Tk::__ANON__ at /Library/Perl/5.8.1/darwin-thread-multi-2leve...',...) called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 eval {...} called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 Tk::MainLoop() called at /Applications/Ifeffit/bin/artemis line 1627 What makes me crazy is that all was running smoothly before tuesday :-) Cheers Michel -- __________________________________________ Michel Jaouen Universite de Poitiers - UFR Sciences - SP2MI LMP UMR 6630-CNRS Boulevard Pierre et Marie Curie - Teleport 2 BP 30179 86962 Futuroscope - Chasseneuil Cedex France Tel : (33) 5 49 49 67 37 Fax : (33) 5 49 49 66 92 e-mail : Michel.Jaouen(a)univ-poitiers.fr __________________________________________

2 1

news
by Bruce Ravel 02 Jun '04

02 Jun '04

Hi everybody, Today I made another new release of the source code tarball and built a new Artemis executable for windows. Users of each of the three major platforms should read the notes below for information about this release. This will be the last release for a while. June and July will be very busy for me and I will have scant time to work on the codes until August at the earliest. I will be reading bug reports and suggestions and will address them when I get back to work on the codes -- so please continue to send them in. Hopefully whatever bugs are lurking in there will not prove too difficult to work around. This release attempts to fix a problem managing the project folder in Artemis, as reported by Stefano Ciurli. The new version works correctly for me, your milage may vary. If any of you will be at the ISSRNS conference in Zakopane Poland next week, please introduce yourself! I hope everyone has a great summer! (Or a great winter for those of you in the southern hemisphere!) B -------------------- O -------------------- Notes for each of the platforms follow: Linux (and other non-Mac OSX unixes): The source code tarball is on SourceForge and on my web site. If the horae_update script fails, try using the --mirror argument as described in the help text (horae_update -h). Mac OSX: There was no time to make a new installer package. For the time being, you can use the most recent installer package, then update to the latest source code tarball from the command line. This requires downloading the source tarball from SourceForge and unpacking it. Then, from the command line, type "perl Makefile.PL" then "make" then "sudo make install". The last step will prompt for the administrator password. If you run into trouble, ask on the mailing list and one of the Mac users should be able to help you. Windows: There was no time to prepare a new updater package for windows. Virtually all of the changes in my codes since the last updater package have been bug fixes to Artemis. So I have made a new Artemis executable and placed it here: http://leonardo.phys.washington.edu/~ravel/software/exafs/packages/artemis_… If you are up to date with the most recent updater package, just download this executable and overwrite the "artemis.exe" file in the instalation directory: "C:\Program Files\Ifeffit" (or where ever you have ifeffit installed on your computer). -- 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

trap file
by Stefano Ciurli 01 Jun '04

01 Jun '04

Hi Bruce, I installed the new horae (035) and played around with the ZnO tutorial using the new version of Artemis. I called the program in the directory where the ZnO dat file reside from the command line. The project apj1 (run with all the indications in the journal) worked smoothly. As soon as I try to read in the apj2, the following trap message pops up: # Artemis 0.7.005 # This file created at 00:19:09 on 31 May, 2004 # using darwin, perl 5.008001, Tk 804.027, and Ifeffit 1.2.5 # Workspace: /Users/stefano/.horae/stash/artemis.project.3/ The following message was trapped by Artemis on a SIGWARN: Artemis0.7.005warn/Users/stefano/.horae/stash/ARTEMIS.TRAPCODE(0x1e3dff8)/Users/stefano/.horae/stash/artemis.project.3/ at /Applications/Ifeffit/bin/artemis line 1562 main::__ANON__('Tk::Error: could not open /Users/stefano/.horae/stash/artemis...') called at blib/lib/Tk.pm (autosplit into blib/lib/auto/Tk/Error.al) line 488 Tk::Error('MainWindow=HASH(0x8f44c)','could not open /Users/stefano/.horae/stash/artemis.project.3/...','main::nnnn_header at /Applications/Ifeffit/bin/artemis line 4386','main::read_path at /Applications/Ifeffit/bin/artemis line 10872','main::open_project at /Applications/Ifeffit/bin/artemis line ...','main::read_data at /Applications/Ifeffit/bin/artemis line 6901','main::dispatch_read_data at /Applications/Ifeffit/bin/artemis...','main::__ANON__ at /Applications/Ifeffit/bin/artemis line 586','Tk callback for ..frame.menubutton.menu.project_data',...) called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 eval {...} called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 Tk::MainLoop() called at /Applications/Ifeffit/bin/artemis line 1707 End of trap file. Exactly the SAME error message pops out when I try to save a fit as chi(k). Obviously I am stuck... Any help here? Again, there must be some problem with the perl libraries... HELP!!! 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 -- ____________________________________________ 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

3 7

source tarball for horae-035
by Bruce Ravel 01 Jun '04

01 Jun '04

Hi folks, I just released the source code tarball for the latest version of my software. Those of you who use the source can run the horae_update script now. Or, you can grab the new version of the horae_update script from here and try it: http://leonardo.phys.washington.edu/~ravel/software/exafs/utilities/horae_u… The new version allows connection to a local proxy and grabs the tarball from SourceForge. Type "horae_update -h" for help on using the new features. This new version of horae_update is included in the tarball. This release is purely a bug fix release, mostly for Artemis. It addresses all the outstanding issues brought to my attention over the last week, including the problems related to the Mac OSX package. A windows executable will be made next week. Thanks to all the folks who provided bug reports for this release, including Shelly Kelly, Stefano Ciurli, Gleb Pokrovsky, and Peter Southon. 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/

4 7

Athena normalization and deglitching bugs
by Scott Calvin 01 Jun '04

01 Jun '04

Hi Bruce, I figured I'd post this to the Ifeffit list so that others could be alerted to similar problems, but I'll send you an Athena project file exhibiting this problem separately, so that everyone's in-boxes don't get cluttered with attachments. I'm using Athena 0.8.028 on Windows XP. First of all, on any file, including the copper data that comes with Athena, there is a bug. To see it, go to the deglitch screen, and change Emax by picking a point off the plot. Then replot. From now on, the green "tolerance" lines extend from Emax up to the end of the plot, rather than from Emin to Emax. This seems to affect only the screen display (i.e. it still deglitches the intended range), but it does make it harder to see what will get deglitched. The second behavior is best revealed with the project I am sending you separately. I am not positive it is a bug, but it doesn't match what I would expect. In the project I am giving you, the data is very glitchy (lots of Bragg peaks). Go down to the group labeled SBT/B Bi LIII Merge and plot in E-space with the post-edge line. Does it look right to you? It looks like the normalization line is considerably higher than it should be given the normalization range chosen, with only a few glitches above it. Is that something I don't understand about the way the post-edge line is chosen, or is it displaying the line wrong, or is it calculating it wrong? Thanks--the new features in Artemis are great, by the way. --Scott Calvin Sarah Lawrence College

2 1

Updating problems.
by Dave Baker 28 May '04

28 May '04

Hello all. This message is directed mainly toward Bruce, but if anyone else has any suggestions, please feel free to contribute. For a while now, I have been using Athena and Artemis on my work computer with a broadband internet connection, and all the updates have auto-detected and installed without a hitch. The problem is that now, I want to use the programs on my home computer, for which I am simply too cheap to buy anything better than dialup service. The updater, unfortunately, has choked several times when trying to download and install the 9 updates it says I need. (In fact, one time the echo screen stated that all the updates were installed, but when I restarted and opened Athena and Artemis, I was confronted with the old versions of the programs.) I haven't seen any "new and fully updated windows installers" on either Matt's or Bruce's pages, and it isn't clear to me how to get at the update files without the assistance of the updater itself. (I seem to recall reading that one can simply unzip the ifup_00x.zip file in the Ifeffit directory, run make_bats.exe, and all will be well.) Is there a way I can use the broadband connection at school to grab the updates and install them myself on the home computer without the use of the updater? Or, is there a place that the updater stores the .zip files after it's done updating the program, so I can just grab them off the work computer? Thanks for your help! -Dave ------------------------------------------------------------------------ -- North Carolina State University Dept. of Physics 2700 Stinton Dr. Box 8202 Raleigh, NC 27695 Ph: 919-515-5017 Fax:919-515-7331 email: dabaker(a)unity.ncsu.edu ------------------------------------------------------------------------ --

2 1

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