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

*****SPAM***** Re: [Ifeffit] question about S02 (passive electron reduction factor)
by SCalvin100＠aol.com 28 Feb '04

28 Feb '04

-------------------- Start SpamAssassin results ---------------------- Content analysis details: (5.7 hits, 5.6 required) 0.2 NO_REAL_NAME From: does not include a real name 1.0 FROM_ENDS_IN_NUMS From: ends in numbers -1.5 BAYES_01 BODY: Bayesian spam probability is 1 to 10% [score: 0.0180] 0.1 HTML_MESSAGE BODY: HTML included in message 6.0 DRUGS_APS BODY: Words and phrases selling drugs -------------------- End of SpamAssassin results --------------------- The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

RE: [Ifeffit] question about S02 (passive electron reduction factor)
by Kelly, Shelly D. 27 Feb '04

27 Feb '04

Yu-Chuan, Matt and all, > >> Yu-Chuan wrote: > >> > >> At the beginning of the fitting, the S02(amp) are far away > from 0.9 > >> (just about 0.3). It's much different than Bruce's and Scott's > >> examples. [...] Also, John have said that the S02 value should be > >> around 0.9. That's why I am wondering if there is anything > wrong with > >> my data processing? Does anyone happen to have this kind > of problem? > > > > > > There are several possibilities. One is sample prep. [...] [...] > > Another is normalization.[...] Finally, look at the correlation > > between S02 and sigma2...if it is very high (say 0.95 or > above) it may > > simply be coming up with low estimates for each. > > Yu-Chuan didn't give details of sample prep or data > collection, and I agree with Scott that these are most likely > cause of low S02 factors (Scott mentioned problems with > transmission measurements, and Grant mentioned how > self-absorption can cause similarly low S02 factors for > fluorescence measurements). I also agree with Scott that > poor normalization will affect S02, though S02~0.3 would > indicate an edge step off by a factor of ~3, which is a > pretty big error for normalization. I doubt that is the culprit. > > But: the correlation between S02 and sigma2 is NOT the cause > of a value for S02 being low by a factor of 3. A high > correlation means that a reasonably good fit could also be > found by changing both S02 and sigma2 away from their > best-fit value. This is not at all the same as saying that > either parameter has the wrong best-fit value. In fact, the > correlation between pair of variables says nothing about the > trustworthiness of the best-fit values, only how much the > uncertainties in the best-fit values depend on other variables. > And, just to be clear, the reported uncertainties already > take these correlation into account. > > Yu-Chuan didn't actually say what the reported uncertainties > in S02 were, but it seems that it was small enough so that > S02~=0.3 could be distinguished from S02~=0.9. > > --Matt The degeneracy of the paths included in the fit were not mentioned, and could easily cause the S02 value to be off by a factor of 3. Especially, if you forget that feff has already taken the degeneracy of the path into account, and then you set some N-value to 2 or 3 or 4. I have seen others make this mistake before... Shelly

1 0

Re: [Ifeffit] question about S02 (passive electron reduction factor)
by Grant Bunker 26 Feb '04

26 Feb '04

As a follow-on to Scott's and Bruce's responses, if the samples were measured in fluorescence, the sample self-absorption effects would be a likely explanation for the problem. At the Vanadium edge the absorption length of the sample would probably be short (microns) and you would have to go to some trouble to avoid those problems. There are good correction procedures for that problem (e.g. see papers by Booth and Bridges, Haskell...). grant bunker On Thu, 26 Feb 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: question about S02 (passive electron reduction factor) > (Scott Calvin) > 2. Re: question about S02 (passive electron reduction factor) > (Bruce Ravel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Feb 2004 13:18:29 -0500 > From: Scott Calvin <scalvin(a)slc.edu> > Subject: Re: [Ifeffit] question about S02 (passive electron reduction > factor) > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: <3.0.1.32.20040225131829.00acff58(a)mail.slc.edu> > Content-Type: text/plain; charset="us-ascii" > > Hi Yu-Chuan, > > There are several possibilities. One is sample prep. If you have an > extremely uneven sample (lots of pinholes, etc.) in transmission it can > lead to results like you're describing. Another is normalization. If you're > using Athena for background subtraction make sure you look at the pre-edge > line and post-edge curve and see that they look reasonable. Sometimes if > the background has a funny shape to it Athena can create a post-edge curve > that shoots way up at the edge energy; this could also lead to the effect > you're describing. Finally, look at the correlation between S02 and > sigma2...if it is very high (say 0.95 or above) it may simply be coming up > with low estimates for each. There are, of course, other possibilities as > well, but in my experience those are the most common. > > --Scott Calvin > Sarah Lawrence College > > >This is Yu-Chuan. I am now trying to fit my sample, magnesium > orthovanadate. > >I try to follow Bruce's Cu example and Scott's ZnO example steps and I > found a > >problem come to my fitting. At the beginning of the fitting, the S02(amp) > are > >far away from 0.9 (just about 0.3). It's much different than Bruce's and > >Scott's examples. For Cu and ZnO examples, the fitting results of amp are > >close to 0.9 at the beginning even if you set just four parameters > (guess:amp, > >e0, delr, and ss). Also, John have said that the S02 value should be around > >0.9. That's why I am wondering if there is anything wrong with my data > >processing? Does anyone happen to have this kind of problem? Thank you for > >your help. > > > > > ------------------------------ > > Message: 2 > Date: Thu, 26 Feb 2004 10:43:48 -0500 > From: Bruce Ravel <ravel(a)phys.washington.edu> > Subject: Re: [Ifeffit] question about S02 (passive electron reduction > factor) > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: <200402261043.48841.ravel(a)phys.washington.edu> > Content-Type: text/plain; charset="iso-8859-1" > > > Hi, > > Yesterday we had a question about oddly small S02 values. In his > thorough summary of possible explanations, Scott mentioned this: > > On Wednesday 25 February 2004 01:18 pm, Scott Calvin wrote: > > Another is normalization. If you're using Athena for background > > subtraction make sure you look at the pre-edge line and post-edge > > curve and see that they look reasonable. Sometimes if the background > > has a funny shape to it Athena can create a post-edge curve that > > shoots way up at the edge energy; this could also lead to the effect > > you're describing. > > I thought that a word of explanation about why Athena does what she > does might be helpful to folks. In this email I am going to refer to > data taken on an iron foil. To follow along, fire up Athena and > select "Import a demo project" from the Help menu. Select the > `calibrate.prj' file. This contains an iron foil spectrum. > > Set the plotting range in energy to [-200:1500]. Set the upper bound > of the normalization range to 400. Click on the "post-edge line" > button in the plotting options section. This will plot the data, the > background, and the post-edge line. Note that the post-edge line is > U-saped, diverging from the data a bit at low energy and significantly > at high energy. Note also that the edge step is about 3.05. > > Now set the upper bound of the normalization range to 1700 and click > the red E plotting button. Now the post-edge line goes through the > data and the edge step is about 2.86. > > So what's going on? Well, the post-edge line is determined by > regressing a quadratic polynomial to the data in the user-specified > normalization range. When the upper bound was set to 400, the square > term in the polynomial was quite large because *that* was the > regression to the data over that short data range. When the upper > bound was set to 1700, the square term was a lot smaller, the > post-edge line was closer to linear and it was constrained by the > regression to follow the data over the entire data range. > > Setting the upper bound of the normalization range had the effect of > increasing the edge step by about 6%. Remember that the edge step is > the value of the post-edge line extrapolated back to E0 after the > pre-edge line is removed from the data. With the short energy range, > the edge step is too large and the chi(k) is attenuated. In the > subsequent fit, S02 will have to be similarly smaller to compensate. > In this case it was a 6% effect, but if the post-edge line is really > screwy, the attenuation could be much larger. > > So this was the long-winded way of repeating what Scott said -- plot > the post-edge line and make sure the regression was done such that the > post-edge line goes through the entire data in a way that seems > sensible. It is also, as Scott said, prudent to check the pre-edge > line as well. > > B > > > > -- > ********* PLEASE NOTE MY NEW PHONE, FAX, & ROOM NUMBERS ****************** > > 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 > > > End of Ifeffit Digest, Vol 12, Issue 14 > *************************************** >

1 0

choosing k-weight
by Peter Southon 20 Feb '04

20 Feb '04

Dear Ifeffiters, I'm wondering what principles you have to determine the appropriate k-weight to use for FTs. Until now I've used guidelines from a textbook by Teo, based on the Z of the backscattering atoms: Z > 57; kw = 1 57 > Z > 36; kw = 2 Z < 36; n = 3 Of course you can have different backscatterers around your absorber - I've got C, N and Pt! Are there any other rules you follow? Thanks very much in advance! Peter Peter Southon Post Doctoral Fellow School of Chemistry University of Sydney NSW 2006, Australia +61 2 9351 4425

2 1

Re: [Ifeffit] choosing k-weight
by SCalvin100＠aol.com 20 Feb '04

20 Feb '04

Peter, Of course, the bottom line is that the k-weight shouldn't affect the values of the parameters Ifeffit finds. If it does, it's a sign that the parameters should not be trusted. Often, this happens when the k-range chosen to fit is inappropriate (extends up into a range where the data is dominated by noise, down into a range where the background is poorly chosen, or across a small edge due to a contaminant, for example). I always test my "final" fits at all three k-weights separately to make sure the values of the parameters stay fairly stable. --Scott Calvin Sarah Lawrence College

1 0

RE: [Ifeffit] choosing k-weight
by Kelly, Shelly D. 20 Feb '04

20 Feb '04

> Dear Ifeffiters, > > I'm wondering what principles you have to determine the appropriate > k-weight to use for FTs. Until now I've used guidelines from > a textbook by > Teo, based on the Z of the backscattering atoms: > Z > 57; kw = 1 > 57 > Z > 36; kw = 2 > Z < 36; n = 3 > > Of course you can have different backscatterers around your > absorber - I've > got C, N and Pt! Are there any other rules you follow? > > Thanks very much in advance! > > Peter Hi Peter, I have found it very useful to use all three kweights, simultaneously. You can really cut down of the correlation between the different EXAFS parameters by doing so. This paper shows a model that was fit to the data with all three kweights. Geo. Cosmo Acta 66(22): pp 3855-3871, November 2002. I have been thinking about putting together an Artemis project file that shows how to do this. If there is interest, I would be willing. Shelly

1 0

Re: IFEFFIT updater problem
by Matt Newville 19 Feb '04

19 Feb '04

Hi Jeff, On Wed, 18 Feb 2004, Jeffrey Catalano wrote: > > The IFEFFIT updater is behaving badly. Everytime I start an IFEFFIT group > program, it wants to download the same two updates. I've installed them > three times now (remembering to run the make bat thingy each time). Any > ideas if the problem is with my computer or with the updater? Other than > that everything works wondefully! Hmm, that seems weird. Here's what is supposed to happen with the updater (and I hope you mind me sending this on to the mailing list -- if the problem happens for you, it will probably happen for someone else, and the updater isn't very well documented), and a way that should be able to work around it -- you can skip to the end if you like ;). When the applications apt, artemis, athena, gifeffit, ifeffit, sixpack, and tkatoms run (from the batch files, desktop icon, or start menu), the updater is run before the main application is run. The updater reads two files: C:\Program Files\Ifeffit\updates\updater.ini C:\Program Files\Ifeffit\updates\updater.dat updater.dat holds the current 'local update level' on your machine, which is just a 3 digit number, like 003 or 005. updater.ini holds the time of the last "real check for updates" and how long to wait until the next update should be done. If the last real check was within the last 24hours, the updater stops right there. Actually, the time to wait until the next real check can be set longer with the 'Do not remind me again until' list in the main updater GUI. If it's past the time to do a "real check for updates", the updater fetches the current 'available update level' from the cars webpage: http://cars9.uchicago.edu/ifeffit/updates/update.dat, which currently reads '005'. If it can't reach this web page and read this file in 15seconds, the updater stops. If the 'local updater level' is equal to the 'available update level', you are up to date and the updater stops. If the 'local updater level' is less than the 'available update level', a GUI pops up, and you are told that there are update(s) to install, and asked if you'd like to install them. If you approve, the updates are downloaded one by one and installed. The update packages are all zip files, named as http://cars9.uchicago.edu/ifeffit/updates/ifup_XXX.zip for update level=XXX. The progress of the download and unpacking should be shown in the updater GUI. These updates are unpacked relative to the main Ifeffit directory, typically C:\Program Files\Ifeffit. Each of the updates includes, the file 'updates\updater.dat' to have the 'current update level'. So, if the update ifup_005.zip was installed, updates\updater.dat should say '005', and the updater shouldn't run again until I set the update level on the web page to 006. OK, that's what is supposed to happen. If that hasn't happened and updates\updater.dat does not say '005', a simple solution should be to edit it (notepad, whatever) to say 005 in the first line. I'd be interested to hear if other people are having this problem. Cheers, --Matt PS: a small problem can occur if the updater.exe program itself needs to be updated, as an executable program currently in use cannot be overwritten. So any new updater.exe is written to the 'updates' directory, and you are told to run make_bats.exe. Then make_bats.exe checks for an updater.exe in the updates directory and moves it to the main Ifeffit directory.

1 0

Ifeffit updater
by Peter Southon 19 Feb '04

19 Feb '04

Hello, I'm a little confused about the role of the Ifeffit updater - does it cover just Ifeffit, or Athena/Artemis as well? It has updated my Ifeffit to v1.2.5 fine, but my version of Artemis is still 0.6.009, when Bruce's web page says that 0.6.010 was released last year. Do we have to update Athena/Artemis separately, and if so is there a way for PC users to do this without downloading the entire Ifeffit package again? Thanks, Peter Peter Southon Post Doctoral Fellow School of Chemistry University of Sydney NSW 2006, Australia +61 2 9351 4425

3 2

finding stuff in the archives
by Bruce Ravel 19 Feb '04

19 Feb '04

Hi folks, A while back there was some discussion about indexing the archive of the mailing list. Still a good idea, but I wanted to suggest a user-land solution to the problem. It is possible to find stuff on the archive using Google. This shouldn't be a surprise -- I, for one, cannot imagine how I ever knew anything in the years B.G. (before Google). Try going to http://www.google.com/ and entering this as your search: site:millenia.cars.aps.anl.gov clamp This will return a hit for every entry in the archive that discusses spline clamps. In my last posting to the mailing list, I did this google search: site:millenia.cars.aps.anl.gov imaginary energy The "site:" directive tells google to restrict its search to pages that match that site. I learned about this trick from the book Google Hacks http://www.amazon.com/exec/obidos/ASIN/0596004478/qid=1077200261/sr=2-1/ ref=sr_2_1/002-8270889-0247203 HTH, B -- ********* PLEASE NOTE MY NEW PHONE, FAX, & ROOM NUMBERS ****************** Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/

1 0

imaginary energy correction
by Stanislav Stoupin 19 Feb '04

19 Feb '04

Hello all, I would appreciate if somebody could explain the meaning of imaginary energy correction (Ei parameter). So far I have not found any description of the parameter. If anyone knows of any example on how to use it, please let me know. Stanislav

2 1