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

RE: [Ifeffit] Using more than one E0
by Kelly, Shelly D. 15 Dec '04

15 Dec '04

Hey Scott, One correction, I botched this part: > -----Original Message----- > From: Kelly, Shelly D. > Sent: Wednesday, December 15, 2004 10:06 AM > To: XAFS Analysis using Ifeffit > Subject: RE: [Ifeffit] Using more than one E0 > > Hi Scott, > > See below: > > The MS scheme you outline below seems to treat the E0 due to the > scattering species (I'll call that the "bonus" E0 for lack of a better > term) as being the average of the bonus E0's for all the scattering > atoms > in the path. Thus you give the Cu-O1-Cu1-Cu path as using the average of > the O1 and the Cu1 bonus E0's, while the Cu-O1-Cu-O1 path uses just the > O1 bonus E0. I would naively expect we should be using the sum, rather > than the average. After all, if this bonus E0 is a correction to the > shift caused by the muffin-tin potential FEFF has calculated, shouldn't > a > MS path that bounces off the same atom twice have to use twice the > correction? I feel like there's something basic I'm missing here... > > [Kelly, Shelly D.] The energy shift applies to the entire scattering > event. The scattering event can not be broken down into the sum of the > legs. [Kelly, Shelly D.] Most of the time, it is good to think about the scattering event as being a sum of the legs. If you follow this through you can see why the energy shift is an average rather than a sum. Take two sine waves and displace one from the other by a few eV. Then add them up. The total will have an energy shift that is in between the two that you started out with. --Hence an average rather than a sum. Hence the energy shift for the entire scattering event can be > approximated as an average of the energy shift from each leg. I have > used the average energy shift a lot and found that it works well. I > have never tried using a sum of the energy shifts... I think that in > an extreme limit you can convince yourself that the sum will break down > for an 8 legged paths. The energy shifts are "never" greater than 10 > eV. "never" in my experience. -Hence the answer to your next question. > > Also, what is your experience as to the actual differences in bonus E0's > that you get in ionic compounds? Right now one of my students is working > with Sr(NO3)2... should we really expect the difference in bonus E0's > between the Sr2+ and the oxygen atoms to be more than 12 eV, or does > some > kind of charge overlap from the nitrate ions actually make the strontium > ions behave as if they are less than +2? > > [Kelly, Shelly D.] One full electron of ionic bonding gives about 6 eV. > So that is about the most you would expect from different ions in a > solid. Usually, I have found 3 to 4 eV. You make up most of the > valence state change from the shift in the edge position. I have found > unrealistic energy shifts when I try to use too much chi(k) data at low > k. I'd look there first for you 12 eV shift. > > HTH > Shelly > > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

1 0

RE: [Ifeffit] Using more than one E0
by Kelly, Shelly D. 15 Dec '04

15 Dec '04

Hi Scott, See below: The MS scheme you outline below seems to treat the E0 due to the scattering species (I'll call that the "bonus" E0 for lack of a better term) as being the average of the bonus E0's for all the scattering atoms in the path. Thus you give the Cu-O1-Cu1-Cu path as using the average of the O1 and the Cu1 bonus E0's, while the Cu-O1-Cu-O1 path uses just the O1 bonus E0. I would naively expect we should be using the sum, rather than the average. After all, if this bonus E0 is a correction to the shift caused by the muffin-tin potential FEFF has calculated, shouldn't a MS path that bounces off the same atom twice have to use twice the correction? I feel like there's something basic I'm missing here... [Kelly, Shelly D.] The energy shift applies to the entire scattering event. The scattering event can not be broken down into the sum of the legs. Hence the energy shift for the entire scattering event can be approximated as an average of the energy shift from each leg. I have used the average energy shift a lot and found that it works well. I have never tried using a sum of the energy shifts... I think that in an extreme limit you can convince yourself that the sum will break down for an 8 legged paths. The energy shifts are "never" greater than 10 eV. "never" in my experience. -Hence the answer to your next question. Also, what is your experience as to the actual differences in bonus E0's that you get in ionic compounds? Right now one of my students is working with Sr(NO3)2... should we really expect the difference in bonus E0's between the Sr2+ and the oxygen atoms to be more than 12 eV, or does some kind of charge overlap from the nitrate ions actually make the strontium ions behave as if they are less than +2? [Kelly, Shelly D.] One full electron of ionic bonding gives about 6 eV. So that is about the most you would expect from different ions in a solid. Usually, I have found 3 to 4 eV. You make up most of the valence state change from the shift in the edge position. I have found unrealistic energy shifts when I try to use too much chi(k) data at low k. I'd look there first for you 12 eV shift. HTH Shelly

1 0

RE: [Ifeffit] Using more than one E0
by Kelly, Shelly D. 14 Dec '04

14 Dec '04

Hi Guys, I wanted to add another comment about using multiple E0's. One of the best formulas that I have found involves assigning different atom types different E0's. This method seems to work well for M.S. paths. Here is an example of how it goes. I think that Daniel Haskel was the first to publish this type of E0 stuff. "Single and multiple scattering XAFS in BaZrO3: a comparison between theory and experiment" D. Haskel, B. Ravel, M. Newville and E. A. Stern Physica B 208&209 (1995) 151 Lets pretend that we have a copper oxide that we want to model. First shell Oxygen called O1, Second shell Cu called Cu1, Third shell Oxygen called O2. This method would use three E0's. One for the first shell oxygen atoms, Eo1. One for all the Cu atoms Ecu. and one for all other oxygen atoms Eo2. The Cu-O1 path has E0=Eo1. The Cu-Cu1 path has E0=Ecu. The Cu-O2 path has E0=Eo2. The Cu-O1-Cu-O1 path has E0=Eo1, (only scattering from O1 atom). The Cu-O1-Cu1-Cu path has E0=0.5*Eo1+0.5*Ecu. (scattering once from O1 and once from Cu1) ... And so forth and so on. Now if you set something like this up. You need to look at the results carefully and see if it works. Generally, scattering from an atom that has lost an electron due to an ionic bond will have a positive deltaE, and scattering from an atom that has gained an electron will have a negative deltaE. Of course this negative/positive deltaE is added to the alignment deltaE. If the values for Eo2 and Ecu are the same within the uncertainties of the measurement then you need to make them the same variable, so then you will only have two energy shifts, but you can still use it. This is most often the case as Matt mentioned but I always like to test it out. In addition, one electron transfer is about a shift by 6 eV, so if these values differ by more than say 10 eV something is not right. Since the shift is generally smallish, say 2 eV, your fit has to be really accurate to "see" these shifts. In particular they seem to be most important when you have all the deltaR values constrained in some way so that the error in deltaR is really really small. For example all deltaR values are related to unit cell parameters and atomic positions or and overall expansion term. HTH Shelly -----Original Message----- From: Wojciech Gawelda [mailto:wojciech.gawelda@epfl.ch] Sent: Thursday, May 27, 2004 1:18 PM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: [Ifeffit] Using more than one E0 Hi everybody, I would like to address a couple of questions which are partially related to my recent struggles in fitting some EXAFS data. I'm trying to fit my data using several shells of different neighbors including a few single scattering paths and also so multiple scattering contributions (mainly collinear multiple scattering paths) all calculated with the help of FEFF 8.20. Now, I found once in the FEFFIT manual the following suggestion: one might consider using several different E0's for different paths in order to improve the fit. Ok, the explanation was based on some approximations coming from FEFF code which include incomplete core-hole shielding, lack of angular variations of the valence charge distribution and charge transfer between atoms in polar materials. My question is the following: does anyone of you have some experience with such procedure? And if yes, shall than distinguish between the first shell of nearest neighbors and the rest of the atoms in terms of their E0 corrections (using 2 parameters)? Or perhaps one can use separate E0's for each path? That's one thing... The second question concerns the background correction in Artemis: I was trying to find an easy explanation of what this procedure does during the fit but I guess I'm still somewhat confused...how one can judge whether the spline co-refinement does the right job? Some people on this mailing list underline that one should avoid high correlations between fitting parameters and background parameters in order to make sure that the fit is correct. But is it the only criterion? In some of my fits background line looks kind of constant over the entire R-range which was taken into the fit. Sometimes it becomes like a modulation peaking underneath some scattering paths...even if the background parameters don't correlate significantly with fitting parameters I have my doubts whether the result is trustful. Any hints about this procedure? Well, I'll greatly appreciate any comments and feedback from all you guys. I hope I'll be able to share some of my own soon :-) 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 *********************************************************************

2 1

RE: [Ifeffit] a question about the white line
by Kelly, Shelly D. 14 Dec '04

14 Dec '04

I just put a background tutorial on my web page. Complete with project files and a pdf showing screen shots and some instructions. It used MoO3 which I found to have a particularly tough background. I used a theory to remove the background and then showed how to reproduced the "same" chi(k) data without the theory. If anyone wants to play with the background and add suggestions I will incorporate more info. Here is a link to the tutorial: www.mesg.anl.gov/skelly.html Shelly > -----Original Message----- > From: Newville, Matthew G. > Sent: Sunday, December 12, 2004 11:03 PM > To: XAFS Analysis using Ifeffit > Cc: John J. Rehr; Joshua Kas > Subject: RE: [Ifeffit] a question about the white line > > Hi John, Josh, > > > Certainly if a spline can do a good job of fitting the mu_0, then the > current > > approach is more or less ok. However in systems with strong white lines > > mu_0 can be strongly peaked and hence very difficult to fit with a few > > spline points. The broadening function lamda(E) can be constrained to be > small. > > Also, for cases with large whitelines, the location of e0 is difficult > to > > fit - the true e0 can lie well below the edge jump. > > Oh, maybe I misunderstood. Is lambda(E) in > > mu_0 = mu^thy_0(E,E_0,Gamma)[1 + lambda(E)] > > just a broadening term or a highly adjustable spline?? I guess > the whole question is how much freedom this function has. > > It definitely sounds interesting to use a theoretical mu_0, > especially for challenging white lines, but it's not clear how to > best make this accessible to users. I'll probably have to think > about this some more, but it would be nice to know the mechanics > of how you're doing it, and how well you need to know the > structure before you start. > > > In our view, mu0 does not depend very much on structure, since it's > > mostly determined by the local embedded atom potential. For this reason > > it's calculation would also be quite fast (only phase shifts and the > > cross-section are needed) compared to a calculation of chi(k) which > > requires multiple scattering paths. > > Well, usually a standard for autobk only needs a decent guess of > the first shell. Getting a standard does require some prior > knowledge of the system and calculation time, but I don't know > that it would be a lot more knowledge and time than would be > needed for a mu^thy_0(E). Anyway, it would still be interesting > to compare these two (autobk using calculated chi(k) v. starting > with a mu^thy_0 and massaging it to match data). > > On the other hand, it sounds as if the mu^thy_0(E) for a few dozen > (or few hundreds) challenging systems could be tabulated. That > would make it very fast and very simple to use! > > --Matt > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

2 1

RE: [Ifeffit] a question about the white line
by John J. Rehr 12 Dec '04

12 Dec '04

We very much appreciate Matt's comments on our suggestion suggestion on using a priori theory in fitting the background XAS: >> Thus we have attempted to use the theoretical mu_0 from FEFF as >> an a priori, and spline corrections on top of that. Thus the form >> of mu_0 would be: >> >> mu_0 = mu^thy_0(E,E_0,Gamma)[1 + lambda(E)] >> >> where the theoretical mu^thy_0 has an adjustable edge position >> (E_0) and broadening (Gamma), and lambda(E) is the spline correction >> which includes both instrumental variations with E and theoretical >> errors. Matt Newville makes the following observation: > That sounds interesting. But if you include a spline with the > calculated mu0(E), how important is the mu^thy_0(E)? Like, how > much work do you need to put into mu^thy_0 if you have lambda to > pick up the slack? Certainly if a spline can do a good job of fitting the mu_0, then the current approach is more or less ok. However in systems with strong white lines mu_0 can be strongly peaked and hence very difficult to fit with a few spline points. The broadening function lamda(E) can be constrained to be small. Also, for cases with large whitelines, the location of e0 is difficult to fit - the true e0 can lie well below the edge jump. For example, FEFF8 calculations show that the Re whiteline is almost completely due to the local embedded atomic absorption, whereas the large whiteline in SF6 has a different origin. The difference between these cases is not something that can be determined without the use of a theoretical mu0. Likewise the determination of E0 cannot be done well without theory in such cases. > On the one hand, since a spline is needed, it might imply that you > don't really gain much. On the other hand, it might also imply > that you could calculate and tabulate a reasonable 'universal > background function' for any given absorber-scatterern pair as a > starting background curve. Otherwise, it seems to me that the > prior information that goes into getting mu0(E) might be roughly > equivalent to using Feff to generate a standard chi(k) for autobk. In our view, mu0 does not depend very much on structure, since it's mostly determined by the local embedded atom potential. For this reason it's calculation would also be quite fast (only phase shifts and the cross-section are needed) compared to a calculation of chi(k) which requires multiple scattering paths. > Anyway, I'd be interested in comparisons of this with autobk > with/without a standard chi(k). And, of course, code donations > for improved algorithms are always welcome. ;). Us too! We would also be interested in sharing our code developments, e.g., eventually integrating them into ifeffit if appropriate. Josh Kas John Rehr

2 1

RE: [Ifeffit] Re: EXAFS-Question concerning \delta(k)
by Kelly, Shelly D. 10 Dec '04

10 Dec '04

Hi, > -----Original Message----- > From: Newville, Matthew G. > Sent: Wednesday, December 08, 2004 11:27 PM > To: XAFS Analysis using Ifeffit > Cc: Frank Haaß > Subject: Re: [Ifeffit] Re: EXAFS-Question concerning \delta(k) > > Hi, > > Bruce summarized Frank's questions about phase shifts as: > > > If I understand your question, there are two parts. (1) Why is > > the shift due to the phase correction always negative (i.e. > > always to a smaller value in FT[chi(R)])? And (2) Why is the > > shift always in the neighborhood of 1/2 angstrom? > > I think there is a simple way to picture why the phase shift is > negative in terms of the quantum mechanical 'scattering from a > potential' problem -- the one where you usually end up talking > about tunneling through a barrier. I'll give it a try: > > ____ ~~~~~~~> ____ > ~~~~~~>| | E<V0 | | E>V0 > __| |__ __| |__ > > > Here we're in the E>V0 regime (on the left). We normally think of > the photoelectron as having energy E= hbar^2k^2/2m, where k is the > wavenumber for the 'free' photoelectron (that is, having escaped > the central atom and far from the scattering atom). But to > participate in the EXAFS, it does leave the absorbing atom and > scatter from the neighbor. When it is near the strong potentials > of the central and scattering atom, the wavenumber would be better > written like > k = sqrt[ 2m * (E-V0)] / hbar > > as for the barrier above (where V0 is the potential energy). > That is, k is lower (the electron wavelength is longer) in the > presence of a strong potential: kinetic energy being traded for > potential energy. > > To describe the EXAFS, we use only k with V0=0, which overestimate > the average kinetic energy of the photoelectron. That means we get > fewer periods of oscillations for a given R than 2*k*R would > suggest, which leads to the negative direction of the phase shift. > [Kelly, Shelly D.] I think that my explanation for a negative phase shift is just the same, but slightly easier for my brain to comprehend. Which means that I'll make some mistakes but it works for me..:) The photoelectron is negative and it scatters off of the electrons from the surrounding atoms. Hence the photoelectron is slowed down when it gets close to the other electrons. Negative and Negative repel, giving rise to fewer periods of oscillations, and a negative phase shift. As for the magnitude of the shift, lighter elements have a larger shift than the heaver elements. You can think about that by remembering that lighter elements scatter more at low k. If you have a photoelectron that scatters with very little energy (moving slowly) it will be slowed down more by the electrons. Heaver elements scatter more at high k. So, a photoelectron that scatters with a lot of energy will not get slowed down as much, hence a smaller phase shift. HTH Shelly

2 1

Compiling Ifeffit wrapper, Athena, etc on AMD64 Linux Box
by mjpushie＠ucalgary.ca 09 Dec '04

09 Dec '04

I've been running in to some problems getting Athena, Artemis, and the other add-on packages to ifeffit, compiled on my AMD Athlon-64 Linux box (running Fedora Core 3, 64-bit version). I can run "perl Makefile.PL" without any problems and get the message: Yay! Now type "make" then "make install" to finish ... Once I run "make" it gets to the point of putting everything together and I get the following message (after the rest of it appears to run successfully): gcc -shared ifeffit_wrap.o -o blib/arch/auto/Ifeffit/Ifeffit.so -L/usr/local/lib -lifeffit -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/bin/ld: /usr/local/lib/libifeffit.a(ifeffit.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libifeffit.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [blib/arch/auto/Ifeffit/Ifeffit.so] Error Thus far I have: 1) Successfully installed PGPLOT-5.2.0, editing the makefile to read: LIBS=-L/usr/X11R6/lib64 -lX11 `$(SRC)/cpg/libgcc_path.sh` -lgcc -lm -lc instead of ... -L/usr/X11R6/lib -lX11 ... 2) Successfully installed ifeffit-1.2.6 after editing: src/Makefile src/cmdline/Makefile src/test/Makefile to contain: PGPLOT_LIBS = -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib64 -lX11 instead of ... -L/usr/X11R6/lib -lX11 ... 3) Successfully installed Tk-804.027 after editing Makefile.PL to read: X11LIB=/usr/X11R6/lib64 4) began installing the ifeffit wrapper, athena and artemis with $ perl Makefile.PL (which completed successfully) $ make (gives errors) I've edited the Makefile in the horae-046 directory where ifeffit_wrap.c and ifeffit_wrap.o are located to append -fPIC following the call to gcc, producing: gcc -shared ifeffit_wrap.o -fPIC -o blib/arch/auto/Ifeffit/Ifeffit.so -L/usr/local/lib -lifeffit -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/bin/ld: /usr/local/lib/libifeffit.a(ifeffit.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libifeffit.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [blib/arch/auto/Ifeffit/Ifeffit.so] Error 1 I'm no compiling wizard, and I'm not even certain that -fPIC is supposed to be passed to gcc in this manner. Is there some other way around the whole shared/static thing, or is this not even the real issue? If anyone on the list has any suggestions, by all means please send them along. I'd like to get some work done!! Sorry for the length of the post. Jake

4 3

Re: EXAFS-Question concerning \delta(k)
by Bruce Ravel 08 Dec '04

08 Dec '04

Frank, I am taking the liberty of forwarding my answer to the Ifeffit mailing list. I am not sure that I can answer your question entirely to your satisfaction and thought it would be useful to offer it up to the list for more commentary. > It is well known that there is a difference in the peak maxima of the > Fourier transformed EXAFS, G(r), and the "real" pair distribution function, > say F(r). As I have observed in spectra taken on pure metals, the maxima of > G(r) and the calculated core-shell-distances (calculated out of the crystal > structure) coincide pretty good. On oxidic samples, this is not the case, > G(r) is always shifted to lower r-values, about 0.5 \AA, sometimes even > almost 1 \AA. I agree that the shift due to the phase might be smaller for a pure metal than for an oxide, but it isn't 0. For copper, for instance, the highest point of the first peak is about 1/4 angstrom lower than the distance to the first shell. > It is always said that this difference is due to the phase shift \delta(k) > in the EXAFS equation, but I have not found a reasonable explanation, WHY > \delta(k) is influenced in this way! What are the parameters "behind" > \delta(k)? > > Maybe you have a little time to answer my question, because I am really not > satisfied with the explanations I found in literature. If I understand your question, there are two parts. (1) Why is the shift due to the phase correction always negative (i.e. always to a smaller value in FT[chi(R)])? And (2) Why is the shift always in the neighborhood of 1/2 angstrom? This is one of those things that I take for granted and rarely think too hard about. Here are my stabs at decent answers to your questions. I'll try the second part first. I wnet all the way back to the Lee and Beni paper from 1977 (Phys Rev B v.15 #6, p. 2862) which shows some plane wave calculations of the various central atom phase shifts. (There are lots of reasons to look at later papers as we now know that curved wave effects are very important, but for motivating a quick 'n' dirty understanding, it is useful to think about plane waves.) These are shown in Fig. 5 on page 2868. There is a Z dependence -- Rh is very different from Mg in the plot -- but all of them have essentially the same k dependence. That is, the traces in that plot are roughly parallel. We can approximate those phase shifts as linear -- 2delta = a*k + b. (They are obviously not linear but the quadratic term isn't huge, and it's helpful to keep the argument simple.) With this assumption, we are Fourier transforming an exafs function with a sine term like this: sin( 2kR + a*k + b) = sin( (2R+a)*k + b ) When you Fourier transform this, the peak will be shifted away from the "correct" R value by a/2. As you can see in the figure in Lee&Beni, all these functions are downward-sloping. Thus a is a negative number, resulting in an inward shift of the peak. All the central atoms have about the same slope, so they are all shifted by about the same amount. Any variation would have to do with the phase shift of the scatterer. So why is the slope of the central atom phase shift always negative and never positive? I think I am going to be less helpful for this question, but maybe someone else can pick up the slack. When you solve the problem of scattering of partial waves off a hard sphere, you find that each partial wave has a phase shift of -pi/2 times the angular momentum of the partial wave. That is, the effect of the scattering is to *decrease* the phase of the particle scattered in a way that is dependent on the angular momentum. An atom isn't a hard sphere and the calculation is a lot harder than for a hard sphere, but the essential physics is the same. Of course, this discussion has been hand-waving. For a proper understanding of all this stuff, I recommend the important Rehr-Albers review of XAS in Rev. Mod. Phys. v.72 #3 (2000) pp 621-654. Indeed, anyone who does XAS regularly should probably keep a copy of that paper on the desk. HTH, B > Thanks!! > > Yours, > > Frank > > --- > Dipl.-Ing. Frank Haass > Darmstadt University of Technology > Institute for Materials Science / Structure Research > Petersenstrasse 23 > D-64287 Darmstadt > > Tel.: +49 (0) 6151 16-2697 > Fax: +49 (0) 6151 16-6023 > > eMail: haass(a)tu-darmstadt.de -- 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

RE: [Ifeffit] a question about the white line
by Kelly, Shelly D. 08 Dec '04

08 Dec '04

Hi Bruce, I have worked with tough background removals. They are particularly difficult the first time you encounter each one. My methodology goes something like this. It isn't easy and sometimes very frustrating. 1) Determine how broad the rise in the adsorption edge. How many eV is it from the bottom to the flat part above the edge. If you edge is broad > 10 eV then Ezero will be somewhere high on the adsorption edge. If you edge is sharp then Ezero will be somewhere low on the adsorption edge. 2) Remove the background. Look at the FT with all three k-weights. Determine if Rbkg is reasonable. 3) You must have a good idea about the first shell. Run Feff and look at the theory with all variables set to zero, Ezero =0, sigma2=0 and delr=0. If you have a split shell be sure to include all the paths that make up the first peak in the FT of the data. 4) Compare theory to data using a well padded k-range. Leave out the first two oscillations in k, starting around 4 to 5 inverse angstroms. Set Ezero equal to zero. Run a fit, determine delr for the paths and sigma2. Look at the fit and the data in k-space with all three k-weights. Check to see if delr and sigma2 are reasonable. See if you think that moving Ezero around in Athena will help line things up at low k. 5) Import the "fit" into Athena and use it as the theory. Remove the background moving Ezero to line up the data and the theory at low k. And then start all over. 6) This procedure will not work if you use the wrong theory hence the frustrating part. HTH - If someone on the list is willing to try this procedure out and gets stuck and you are willing to share all. I will continue to help on the mailing list. Shelly Shelly Kelly ---------------------------- skelly(a)anl.gov Bldg 203, RM E113 phone: (1) 630-252-7376 Argonne National Laboratory fax: (1) 630-252-9793 Argonne, IL 60439 www.mesg.anl.gov > -----Original Message----- > From: Bruce Ravel [mailto:ravel@phys.washington.edu] > Sent: Tuesday, December 07, 2004 3:00 PM > To: XAFS Analysis using Ifeffit > Subject: Re: [Ifeffit] a question about the white line > > On Tuesday 07 December 2004 03:47 pm, you wrote: > > Hi Bruce, > > > > Feel free to have them contact me. I have done a lot of Re compounds. > > > > Jeff > > Hmmm.... The point of a mailing list is to have a public, searchable > archive where useful information can be discussed and shared in an > open manner. > > I could have just answered the question myself, but I thought that it > was one of broad interest. Thus I had hoped to solicit discussion on > the mailing list. > > 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/ > > > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

5 6

Frustrating monochromator glitch
by m.bondin＠pgrad.unimelb.edu.au 08 Dec '04

08 Dec '04

Dear mailing list - my last round of EXAFS experiments performed on the Fe-K edge in fluorescence mode gave data extending nicely to 15 in k. One problem was a nasty monochromator glitch at approx 13.5 in k which is so great in some cases it causes sufficient distortion to the data that even upon deglitching I must cut back the data to 13 in order to gain a good fit using my models. Firstly I was wondering if someone here could describe to me how a monochromator glitch arises (some systematic defect in the monochromator crystal or more? - the only problem with this explanation is that some data sets seem more affected than others and it has not manifested itself as badly in previous trips). Also is there any other way to handle the removal of a monochromator glitch besides deglitching? My supervisor seems to think that there must be a scale factor or offset in the I0 monitor counts which could be corrected in order to overcome a glitch in the existing data - has anyone ever ! thought of other ways to salvage data in this way? Regards, Mark -- Mark Bondin PhD student School of Chemistry, University of Melbourne (03) 8344 7015 (Tower lab) 0409 252 983 (mobile)

3 2

RE: [Ifeffit] a question about the white line
by Barton, David (DG) 08 Dec '04

08 Dec '04

Friends, Thanks Bruce for forwarding the question to the Ifeffit mailing list regarding background subtraction for samples with strong white lines. The Re sample that sparked the question is attached (white line >3mu). The data is not perfect, but it is good enough for discussion. My first approach to subtracting the background was similar to what Matt mentioned (Matt said: "I know others regularly use kmin >1"), this method seemed to work fairly well using kmin= 1.5 and Rbkg = 1.0. I then used Matt's suggestion to shift the Eo and keep kmin = 0.5, this method ultimately gave a similar subtraction albeit with a phase shift that should be taken care of when the data is fit to theory. It will be interesting to compare the results of the fit using these two methods of background subtraction, especially the first shell which is a Re-CO that has a short distance and is sensitive to background subtraction. Thanks, Dave _________________________________ David Barton, PhD The Dow Chemical Company Catalysis R&D 1776 Building Midland, MI 48674 USA Ph: (989) 636-4753 Fax: (989) 638-6225 Email: dgbarton(a)dow.com

1 0

RE: [Ifeffit] a question about the white line
by Kelly, Shelly D. 08 Dec '04

08 Dec '04

> -----Original Message----- > From: Newville, Matthew G. > Sent: Tuesday, December 07, 2004 11:17 PM > To: XAFS Analysis using Ifeffit > Subject: RE: [Ifeffit] a question about the white line > > Shelly, > > That seems like a lot of steps to me, and it almost seems like > you're mimicking by hand the use of a standard chi(k) with > autobk/spline(). Do you find very different results using a > standard chi(k) with autobk/spline()? If so, do you have any > suggestions for how the more automated version could be improved? > [Kelly, Shelly D.] Hi Matt, You are right. My method does use a lot of steps. I have seen "large" differences in the background removal for the first two full cycles in k-space. I will show a figure, soon. But often what happens is the default spline cuts the EXAFS data too many times through the edge. Your suggestion for an automated approach is a good one. Here is an idea. (1) Set kmin high in the spline range, so that you do not use the first two oscillations in k. (2) Fit the first shell, in a way that makes sense. (3) Use the theory to remove the background using kmin=0 in the spline range. As Matt points out you can tell if the theory is reasonable by the shape through the white line region. You will get to the same place as before. -Assuming that you use a reasonable theory and your original choice of Ezero is not too far off. I will try it out on some tough data and let you know how it goes. Shelly

1 0

Exporting data to Igor
by Gerrit Schmithals 08 Dec '04

08 Dec '04

Hello, I now frequently use the possibility of exporting data from Athena to my analysis software Igor Pro 5. I have a few suggestions on the exporting behaviour: - The abscissa-column of exported BFT data (q-space) is wrong when using File | Save marked group as data | ... This applies to the magnitude, real and imaginary part. Obviously the R-space values are used instead of q-space as can be seen from the column header. When using File | Save chi(q) no problems occur. (see Data.zip, Athena 0.8.034, Ifeffit 1.2.6a) - Along with exporting the data I also use Edit | Write a report | CSV report (marked groups) to get a printout of all parameter values with which the data was processed. I have written a small script for Igor to read that data into a text wave from where it can be displayed or used in further routines e.g. to automatically be displayed in a graph. If anyone is interested I can post that script. Bruce, if there is time left for it, could you also include the value of the check button 'Phase correction' along with the exported data? (BTW: The unchecked button displays either 'No' or 'Off' but it seems irrelevant) Cheers, Gerrit

2 1

a question about the white line
by Bruce Ravel 07 Dec '04

07 Dec '04

Hi, Last week I was asked an interesting question. A long-time ifeffit user was showing A&A to some grad students new to the XAS biz: [An] issue that came up with them as they began to use the software was: Dealing with background substraction from compounds with enormous white lines (Re data). I thought it would be useful to hear comments from people on the mailing list. Any takers? 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

RE: [Ifeffit] Re: Ifeffit Digest, Vol 22, Issue 1
by SCHLEGEL Michel 177447 06 Dec '04

06 Dec '04

> > But: I'm not aware of any beamline saving data in mono steps. > > AFAIK, only the old Lytle data is in this format. We should not > > do anything to encourage this very bad practice. For the record, > > it's bad because it assumes you know: 1) steps per degree, 2) > > value of steps at angle=0, and 3) lattice spacing of crystal. If > > you don't know all three values, you have nothing. > > > > So, I agree it would be foolish to try to support every beamline > > format, and not likely to be successful. I also think putting in > > the lattice constant for YB66 or polynomial coefficients for the > > thermal expansion curve of Si is a similarly doomed. > > > > I think that Matt is right. > > It is a shame to waste the old Lytle data, but let us not > allow that to continue. If someone really wants the data > from that old Lytle data bank then there are inconvenient > ways to extract the information, just as it should be. Would it be advisable - realistic to convert once and for all the old Lytle data from the mono step scale to the energy scale? (I mean, by wirtue of a well-hacked perl macro). Is there any scientific reason why the old mono step scale should be kept? > I second the "Athena test". As such, spec files with all scans cannot be read by Athena, but you can copy out individual "scans" in separate files, for which comment lines all start with "#", the last line given the name of the motors and detectors ("energy", "IO"...) and the data is then ordered as an array. The promblems are (1) usually all scans (table, slits...) are collected in one file, and (2) the column ordering varies from file to file (a problem which is already wonderfully addressed by Athena, though). So maybe a separate splitting macro to take out the do the job would be more convenient than asking athena to do all theis work. Granted it's tedious, but compared to the time needed to correctly extract, interpret & fit the data... Michel

5 8

Re: differential evolution algorithm (fwd)
by Grant Bunker 02 Dec '04

02 Dec '04

Carlo suggested that I submit this (edited) to the ifeffit list... gb ---------- Forwarded message ---------- Date: Thu, 2 Dec 2004 21:40:54 -0600 (CST) From: Grant Bunker <bunker(a)agni.phys.iit.edu> To: Carlo U. Segre <segre(a)iit.edu> Cc: Bruce Ravel <ravel(a)phys.washington.edu>, Grant Bunker <bunker(a)biocat1.iit.edu> Subject: Re: differential evolution algorithm Hi, Carlo - DE is a very nice and simple genetic algorithm for finding global minima. As far as I know I have been the only person applying it to XAFS. It might be overkill for the application though - is this just for finding maximum in the edge derivative? If it is, it's probably simpler just to smooth the data (e.g. with binomial smoothing which you can do by repeated convolution Y(n)=y(n+1)+2*y(n)+y(n-1))/4), followed by a derivative. I've done it that way before (or use smoothing splines) in the distant past and it worked fine. In the edge-finding hack in the mathematica notebook (for automated data reduction) I sent you I just used differential evolution out of laziness, but it's very good for more difficult fitting problems like the stuff we have been doing with the ab initio DWFs in enzymes. It's arguable whether using the max derivative is the best way to choose E0 anyway, but that's a different story. thanks - grant ps I googled "differential evolution" and uncovered a good web site at berkeley. Probably it has references to the original article by storn and price. A couple of years ago I implemented it in Mathematica code for global fitting calling feff as an external "function". The intrinsic NMinimize function in Mathematica also has it available as a minimization method in purely numerical (nonsymbolic) calculations. http://www.icsi.berkeley.edu/~storn/code.html On Thu, 2 Dec 2004, Carlo U. Segre wrote: > > I am somewhat ignorant. Grant uses the builtin function from Mathematica. > Perhaps he can give a bit more information. Grant? > > Carlo > > On Thu, 2 Dec 2004, Bruce Ravel wrote: > > > > >> Grant has been using a differential evolution algorithm to take case of > >> noisy data. Perhaps this could help? > > > > Carlo, > > > > Is there a reference for this in the exafs conmtext? I'd like to read > > up on it. > > > > B > > > > > > > > -- > 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 >

1 0

RE: [Ifeffit] Too many points in pre-edge
by Barton, David (DG) 02 Dec '04

02 Dec '04

Carlo and Matt: > With these files, the location of the edge (and element > identification as well) using the first derivative > does not work. I also had a similar problem when we had a somewhat noisy pre-edge and edge data. Often our analysis of the XANES requires high confidence in the edge energy to determine energy shifts and to accurately align our spectra using metal foil references. Of course, I can always manually assign the edge position in Athena, but it would be nice if Ifeffit was a bit smarter about how it chooses Eo since it is critical for Athena operation when a reference standard is used to calibrate a sample spectra. I would guess that there is some robust algorithm that one could implement which would more accurately determine either (1) the maximum in the first derivative or (2) the zero of the second derivative for data with any number of data points or noisy data. I imagine that such an algorithm would include some sort of adjustable "smoothing" parameter to filter the signal from noise. Dave _________________________________ David Barton The Dow Chemical Company Catalysis R&D 1776 Building Midland, MI 48674 USA Ph: (989) 636-4753 Fax: (989) 638-9350 Email: dgbarton(a)dow.com > -----Original Message----- > From: ifeffit-bounces(a)millenia.cars.aps.anl.gov > [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On > Behalf Of Carlo U. Segre > Sent: Thursday, December 02, 2004 9:44 AM > To: IFEFFIT Mailing List > Subject: [Ifeffit] Too many points in pre-edge > > > > Matt: > > I am running into a somewhat annoying problem with > continuous scan data > imports into athena where there are many datapoints before > the edge (I > think > 400 or so). With these files, the location of the > edge (and > element identification as well) using the first derivative > does not work. > The edge is identified as being somewhere in the pre-edge. > As I reduce > the number of data points in the pre-edge, the edge > identification moves > closer to the true edge and then locks in correctly when > the number of > data points in the pre-edge is small enough (again, I think > this is less > than 400 points). > > I can address this problem by running these data through a > rebinning > process in the pre-edge but I think that if it is possible > to handle this > in ifeffit, that would be a good idea. > > On a second note, would you tell me whether you or Bruce is > planning to > maintain the ifeffit perl wrapper? At this time, ifeffit > 1.2.6a and horae > 046 have different versions of the Ifeffit.pm script (1.3 and 1.301 > respectively). I recently ran into a problem because I had > the ifeffit > version and horae 046. > > 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 > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >

4 5

RE: [Ifeffit] Re: Ifeffit Digest, Vol 22, Issue 1
by Kelly, Shelly D. 02 Dec '04

02 Dec '04

> > I want to go back a step. First, you asked what commonly used > crystals athena should know about. I think the answer should be > "None". Athena should not be the tool to convert mono steps to > energy. It should not know the thermal expansion curve for Si. > The beamline should supply values in units of energy or wavelength > or provide software to convert to such units. > > Then the discussion got to supporting data formats from different > beamlines. I don't disagree with your desired formatting rules. > For what it's worth, I think we (that is, those on this email > list) are as qualified to set such a standard as the IXS (or at > the very least, we're approximately a quorum of any such group of > the IXS). Here's a proposed draft 0.1 for a data format standard > for beamline collection software: > > The data can be read and used by Athena without modification. > > Whether any such standard is actually used is a different matter. > At the APS there are at least six different beamline data formats > used for XAFS (there might be more than that: I'm pretty sure > sectors 4, 5, 10, 12, 13, and 20 each use different formats). At > least 3 of these pass the athena standard. One of those formats > is spec, which does not meet this standard. I believe spec is > used widely at many other synchrotrons. At the APS, some data is > saved in HDF format. HDF may become more common as EPICS seems to > be moving this way. I don't know that any EXAFS data is currently > saved only as HDF, but I wouldn't be surprised if happens. If I'm > not mistaken, SSRL saves data in a binary format. It can be > converted to ASCII, but that still does not meet the 'read by > athena' rule. I believe we had a recent example where data from > SRS was close, but also did not quite meet this standard. > > But: I'm not aware of any beamline saving data in mono steps. > AFAIK, only the old Lytle data is in this format. We should not > do anything to encourage this very bad practice. For the record, > it's bad because it assumes you know: 1) steps per degree, 2) > value of steps at angle=0, and 3) lattice spacing of crystal. If > you don't know all three values, you have nothing. > > So, I agree it would be foolish to try to support every beamline > format, and not likely to be successful. I also think putting in > the lattice constant for YB66 or polynomial coefficients for the > thermal expansion curve of Si is a similarly doomed. > I think that Matt is right. It is a shame to waste the old Lytle data, but let us not allow that to continue. If someone really wants the data from that old Lytle data bank then there are inconvenient ways to extract the information, just as it should be. I second the "Athena test". Shelly

1 0

Too many points in pre-edge
by Carlo U. Segre 02 Dec '04

02 Dec '04

Matt: I am running into a somewhat annoying problem with continuous scan data imports into athena where there are many datapoints before the edge (I think > 400 or so). With these files, the location of the edge (and element identification as well) using the first derivative does not work. The edge is identified as being somewhere in the pre-edge. As I reduce the number of data points in the pre-edge, the edge identification moves closer to the true edge and then locks in correctly when the number of data points in the pre-edge is small enough (again, I think this is less than 400 points). I can address this problem by running these data through a rebinning process in the pre-edge but I think that if it is possible to handle this in ifeffit, that would be a good idea. On a second note, would you tell me whether you or Bruce is planning to maintain the ifeffit perl wrapper? At this time, ifeffit 1.2.6a and horae 046 have different versions of the Ifeffit.pm script (1.3 and 1.301 respectively). I recently ran into a problem because I had the ifeffit version and horae 046. 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

1 0

Re: Ifeffit Digest, Vol 22, Issue 1
by Grant Bunker 01 Dec '04

01 Dec '04

Hi, Bruce - Ge crystals certainly are a must. Shouldn't forget that people use Si monochromator crystals at different temps also. Instead of making a list of d spacings for each reflection, I would just keep values of the lattice constants at a few reference temps and interpolate the lattice constant a for the temp of interest, then any of the d spacings can be calculated as d[hkl]=a/Sqrt[h^2+k^2+l^2] (if memory serves me correctly) Same for Ge and Diamond since they are the same structure. That way it's just a handful of numbers, no big deal. Matt's point as to whether it really should be athena's job to read in all file formats is a good one. Mostly you want to make it easy for a new format to be added by the end user. A scripting language would suffice although perl might be difficult for most people to deal with. Perhaps the equation parser used in ifeffit could be deployed as end-user configurable preprocessor for massaging beamline data into the right form. If those were saveable as templates for different types of data it would be convenient. thanks -grant On Wed, 1 Dec 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. common mono crystals (Bruce Ravel) > 2. Re: common mono crystals (Matt Newville) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 1 Dec 2004 10:24:17 -0500 > From: Bruce Ravel <ravel(a)phys.washington.edu> > Subject: [Ifeffit] common mono crystals > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: <200412011024.17160.ravel(a)phys.washington.edu> > Content-Type: text/plain; charset="us-ascii" > > > Hi folks, > > One of my chores for today is to implement a utility in Athena for > converting encoder readings in a raw data file into energy. This will > make some of the data in the Lytle database a bit easier to use. One > of the things that the user must specify is the d-spacing of the mono > crystal. I want to provide a menu of common crystals. > > The orange book is kind enough to provide an exhaustive list -- but > it's kind of overkill. Somehow I doubt if many people are using a > sucrose 001 monochromator even though that d-spacing is given in the > orange book ;-) (Really! It's on page 4-12!) > > I want to do an informal survey of what crystals the ifeffit crowd > regularly uses. I am certainly going to include Si111, Si311, and > Si200 in the list, so I don't need to hear from people who use those > crystals. What others should go in the list? Beryl? Germanium? > Graphite? Let me know.... > > Thanks, > 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: 2 > Date: Wed, 1 Dec 2004 09:58:12 -0600 (CST) > From: Matt Newville <newville(a)cars.uchicago.edu> > Subject: Re: [Ifeffit] common mono crystals > To: ravel(a)phys.washington.edu, XAFS Analysis using Ifeffit > <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: > <Pine.LNX.4.44.0412010940170.26700-100000(a)millenia.cars.aps.anl.gov> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Bruce, > > Diamond 111 is fairly common (I'd guess more common than anything > but Si), and you probably meant Si(220) instead of (200). InSb is > probably the next most common for the 1 to 2 keV range. I think > the others are not so common for XAFS as the energy bandpass is > too wide. Also, Si at room temperature is slightly different than > at LN2 temperature.... > > But also needed for that calculation is the number of motor steps > or encoder steps per angular unit. OK, angular unit is probably > most commonly in degrees, but I wouldn't assume that it's never in > radians. For steps per angular unit, it's usually a many thousand > steps per degree but it can be pretty much any number. > > So, it's complicated to convert 'steps' to eV. Personally, I'm > comfortable insisting that the beamline/facility provide energy in > eV, keV, Angstroms. or at least angle in degrees with the > monochromator lattice constant clearly given. > > That is, I don't think this should be athena's job. I think it > would be better to have more support for beamline-specific > formats. Then, if some particular beamline saves the "energy" > in nanoJoules or milliradians that could be marked and > auto-converted, but I don't think athena should worry about what > kind of monochromator was used or steps-per-degree. > > The data in the Lytle archive is possibly a special case, because > it's commonly available. It's usually well marked for conversion > to energy, but the data is poorly documented and spotty in quality > and it's often hard to tell what exactly the columns are (e-yield > v. fluorescence, for example). That can make it hard to asses the > quality of the data (is self-absorption a problem, etc). I do use > it sometimes, but the data is not all that reliable. > > Having a more complete and well-maintained database of data, > including some of the data from the Lytle database would be nice. > Any volunteers to work on that? > > --Matt > > > > ------------------------------ > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest, Vol 22, Issue 1 > ************************************** >

5 5

common mono crystals
by Bruce Ravel 01 Dec '04

01 Dec '04

Hi folks, One of my chores for today is to implement a utility in Athena for converting encoder readings in a raw data file into energy. This will make some of the data in the Lytle database a bit easier to use. One of the things that the user must specify is the d-spacing of the mono crystal. I want to provide a menu of common crystals. The orange book is kind enough to provide an exhaustive list -- but it's kind of overkill. Somehow I doubt if many people are using a sucrose 001 monochromator even though that d-spacing is given in the orange book ;-) (Really! It's on page 4-12!) I want to do an informal survey of what crystals the ifeffit crowd regularly uses. I am certainly going to include Si111, Si311, and Si200 in the list, so I don't need to hear from people who use those crystals. What others should go in the list? Beryl? Germanium? Graphite? Let me know.... Thanks, 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

Importing Athena data into Excel
by sej9＠cornell.edu 29 Nov '04

29 Nov '04

I can't remember how to import chi(r) data from a merged file in Athena into Excel. Sarah

2 1

formula checking
by Peter Southon 22 Nov '04

22 Nov '04

Hello all, I've got a quick question about the checking of formulas. I mistakenly typed "//" instead of "/" into several 'def' commands in my model. Unfortunately it took me a long time to find the mistake, since it was a complex model and by some fluke the equation gave almost (but not quite) the expected value. Since "//" doesn't seem to be a valid Ifeffit operator, why didn't either Ifeffit or Artemis pick it up? Regards, Peter Peter Southon Postdoctoral Fellow School of Chemistry University of Sydney NSW 2006, Australia +61 2 9351 7482

4 4

Rbkg value in Athena
by Ann Liang 18 Nov '04

18 Nov '04

Hi Bruce, I am a little bit confused on what the Rbkg value should be when I do the background subtraction. I have read some previous posts which stated that Rbkg can be determined after the fit. However, I always think that the fit depends strongly on how the background being subtracted. How does the initial spline value affect the background subtraction? Should it be 1eV or 25 eV above the edge? I appreciate your help. Thanks, Ann

3 2

Re: [Ifeffit] formula checking
by Scott Calvin 17 Nov '04

17 Nov '04

Hi Matt, Bruce, etc., I think Matt's suggestion is a very good one. In the past, I have occasionally run into problems where Ifeffit flags a problem but Artemis doesn't check for the particular flag. Since when I'm rolling along using Artemis I don't alsays inspect the Iffefit messages, I didn't realize anything funny has happened immediately...it wasn't until I realized the fit didn't make sense that I checked if Ifeffit had correctly identified a typo or whatever. I've always alerted Bruce when these things have come up, and he's incorporated them into new releases, but it would be very good if Ifeffit had a couple of generic warning flags that Artemis could grab on to and thus prominently alert the user that something went wrong... --Scott Calvin Sarah Lawrence College At 11:08 AM 11/17/2004 -0600, you wrote: >Hi Bruce, Peter, > >Ifeffit does print a warning message about a syntax error on using >'//'. But it's completely believable and forgivable that Artemis >doesn't catch this. > >Bruce, would it help if a flag was set indicating 'syntax error' >in addition to printing the warning message? That way you could >wrap each of the definitions with a perl function that did the >ifeffit command and check for syntax errors, doing something >sensible (popping up a warning dialog box, for example) on a >syntax error. That might be better than checking for '//' itself, >because it would detect other syntax errors as well. > >A flag meaning 'math error' (as on divide-by-zero or sqrt(-1)) >might be useful too, I suppose.... >

1 0