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

Re: [Ifeffit] Re: opening SSRL data with Athena
by Silvio Levy 14 Jan '07

14 Jan '07

Here is how I converted my SSRL-collected data so as to be able to import them into Athena. (By the way, when you collect the data you can specify that you want them in ASCII, but I did not know that at the time.) 1. Install EXAFSPAK, the SSRL-grown Exafs data analysis suite. 2. Run the MVIEW command on each file with instructions to save the output in ASCII. Although the command is interactive, you can run it in quasi-batch mode -- you just have to quit from each window as pops up. This way you can cycle through 100 files or more in a couple of minutes. For example, on Linux, I ran the following shell script for files collected in transmission mode. The key command is mview /num=1-6 /den=1 /write=output-file input-file ********************** #!/bin/sh cd Raw # directory where the SSRL binary files reside for i in `cat list-of-files-to-be-converted` do mview /num=1-6 /den=1 /write=../ASCII/$i $i done # this prints 7 columns (the first being a repeat of energy) # In Athena, select num=5,den=6 for sample, num=6,den=7 for reference ********************** Hope this helps! Silvio Levy

1 0

RE: [Ifeffit] Projekt with the "flatten-problem"
by Kelly, Shelly D. 11 Jan '07

11 Jan '07

Good going Dave. I think that you are correct. Shelly > -----Original Message----- > From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit- > bounces(a)millenia.cars.aps.anl.gov] On Behalf Of Barton, David (DG) > Sent: Thursday, January 11, 2007 10:49 AM > To: 'XAFS Analysis using Ifeffit' > Subject: RE: [Ifeffit] Projekt with the "flatten-problem" > > Jens, > > It appears to me that the E-shift is causing the problems with the step in > the pre-edge data. Shelly's data only appears to remove the step because > the pre-edge and the extrapolated post-edge plots are nearly parallel. If > you adjust the Normalization range in Shelly's data you will see the step > appear again. > > However, if you set the E-shift to zero and reset Eo, pre-edge range, and > normalization range (to your liking) you will see that the step is goes > away. So the work around would be to subtract the E-shift from your Raw > data, then import into Athena and do not use any E-shift. > > Bruce or Matt may have to comment, but it appears to me that the > normalization/flatten routine may not be dealing with the E-shift > appropriately. > > Dave > > >-----Original Message----- > >From: ifeffit-bounces(a)millenia.cars.aps.anl.gov > >[mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf > >Of Kelly, Shelly D. > >Sent: Thursday, January 11, 2007 11:11 AM > >To: XAFS Analysis using Ifeffit > >Subject: RE: [Ifeffit] Projekt with the "flatten-problem" > > > >Hi Jens, > > > >I believe the problem is related to the structure in the data > >before E0. > >If you choose e0 to be at the beginning of the structure then > >the normalization is handled better by Athena. Take a look at > >the attached project file. The first data set with e0 on the > >edge as you would choose for EXAFS analysis (e1) shows the > >error that Jens reported. The second data set with a lower > >value for e0 at the beginning of the structure (e2) gets the job done. > > > >Cheers, > >Shelly > > > >--------------------------- > >Shelly Kelly > >Argonne National Laboratory > >Bldg 203, RM E113 > >9700 S. Cass Ave > >Argonne, IL 60439 > > > >Molecular Environmental Science Group > >www.mesg.anl.gov > >skelly(a)anl.gov > >phone: 630-252-7376 > > > > > >> -----Original Message----- > >> From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit- > >> bounces(a)millenia.cars.aps.anl.gov] On Behalf Of Jens Kruse > >> Sent: Thursday, January 11, 2007 2:38 AM > >> To: Athena mailing List > >> Subject: [Ifeffit] Projekt with the "flatten-problem" > >> > >> Hi, > >> > >> find attached an example with the "flatten-problem". > >> thanks a lot, > >> > >> jens > >> > >> > >> > >> > >> "Hi, > >> > >> I have a normalization problem with Athena. If I turn on the > >"flatten" > >> option in the background removal section, Athena creates in some of > >the > >> normalized spectra a step in the pre-edge range. How can I get rid > >of > >> it? > >> > >> Thanks, > >> > >> jens" > > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

1 0

RE: [Ifeffit] Projekt with the "flatten-problem"
by Barton, David (DG) 11 Jan '07

11 Jan '07

Jens, It appears to me that the E-shift is causing the problems with the step in the pre-edge data. Shelly's data only appears to remove the step because the pre-edge and the extrapolated post-edge plots are nearly parallel. If you adjust the Normalization range in Shelly's data you will see the step appear again. However, if you set the E-shift to zero and reset Eo, pre-edge range, and normalization range (to your liking) you will see that the step is goes away. So the work around would be to subtract the E-shift from your Raw data, then import into Athena and do not use any E-shift. Bruce or Matt may have to comment, but it appears to me that the normalization/flatten routine may not be dealing with the E-shift appropriately. Dave >-----Original Message----- >From: ifeffit-bounces(a)millenia.cars.aps.anl.gov >[mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf >Of Kelly, Shelly D. >Sent: Thursday, January 11, 2007 11:11 AM >To: XAFS Analysis using Ifeffit >Subject: RE: [Ifeffit] Projekt with the "flatten-problem" > >Hi Jens, > >I believe the problem is related to the structure in the data >before E0. >If you choose e0 to be at the beginning of the structure then >the normalization is handled better by Athena. Take a look at >the attached project file. The first data set with e0 on the >edge as you would choose for EXAFS analysis (e1) shows the >error that Jens reported. The second data set with a lower >value for e0 at the beginning of the structure (e2) gets the job done. > >Cheers, >Shelly > >--------------------------- >Shelly Kelly >Argonne National Laboratory >Bldg 203, RM E113 >9700 S. Cass Ave >Argonne, IL 60439 > >Molecular Environmental Science Group >www.mesg.anl.gov >skelly(a)anl.gov >phone: 630-252-7376 > > >> -----Original Message----- >> From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit- >> bounces(a)millenia.cars.aps.anl.gov] On Behalf Of Jens Kruse >> Sent: Thursday, January 11, 2007 2:38 AM >> To: Athena mailing List >> Subject: [Ifeffit] Projekt with the "flatten-problem" >> >> Hi, >> >> find attached an example with the "flatten-problem". >> thanks a lot, >> >> jens >> >> >> >> >> "Hi, >> >> I have a normalization problem with Athena. If I turn on the >"flatten" >> option in the background removal section, Athena creates in some of >the >> normalized spectra a step in the pre-edge range. How can I get rid >of >> it? >> >> Thanks, >> >> jens" >

1 0

RE: [Ifeffit] Projekt with the "flatten-problem"
by Kelly, Shelly D. 11 Jan '07

11 Jan '07

Hi Jens, I believe the problem is related to the structure in the data before E0. If you choose e0 to be at the beginning of the structure then the normalization is handled better by Athena. Take a look at the attached project file. The first data set with e0 on the edge as you would choose for EXAFS analysis (e1) shows the error that Jens reported. The second data set with a lower value for e0 at the beginning of the structure (e2) gets the job done. Cheers, Shelly --------------------------- Shelly Kelly Argonne National Laboratory Bldg 203, RM E113 9700 S. Cass Ave Argonne, IL 60439 Molecular Environmental Science Group www.mesg.anl.gov skelly(a)anl.gov phone: 630-252-7376 > -----Original Message----- > From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit- > bounces(a)millenia.cars.aps.anl.gov] On Behalf Of Jens Kruse > Sent: Thursday, January 11, 2007 2:38 AM > To: Athena mailing List > Subject: [Ifeffit] Projekt with the "flatten-problem" > > Hi, > > find attached an example with the "flatten-problem". > thanks a lot, > > jens > > > > > "Hi, > > I have a normalization problem with Athena. If I turn on the "flatten" > option in the background removal section, Athena creates in some of the > normalized spectra a step in the pre-edge range. How can I get rid of > it? > > Thanks, > > jens"

1 0

Re: ZnO Artemis demo - problem with "dr" parameter
by Scott Calvin 11 Jan '07

11 Jan '07

Hi Craig, I'm cc'ing this to the Ifeffit mailing list, as others may encounter similar problems. It's not your novice-ness that's causing the problem; it's a version issue. I wrote the ZnO example when an older version of the software was current. Since then, "dr" became a reserved variable, and can't be user defined. (Bruce could probably give the reason for that change.) I fixed that, but it looks like the older version of the tutorial is being included with the current distributions of Ifeffit and friends. We'll fix that. In the meanwhile, though, you can just change the variable names by hand to "delr" or something like that (you have to change them in both the GDS screen and the path screens, or course). Sorry about that. Incidentally, there's a related bug in Artemis itself. If you have it automatically come up with variables for you on a new fit, it will name one "dr", and then can't do the fit! :( --Scott Calvin Sarah Lawrence College At 01:24 AM 1/9/2007, Craig Klauber wrote: >Dear Scott, > Sorry to bug you on what may be a very trivial issue - but if >its a quick fix a bit of guidance would be very much appreciated. > I've been working through your ZnO demo tutorial on Artemis and >everything worked well until I received the following warning message from >Artemis after trying to Fit at the beginning of part 2. The Fit then aborts. > >"This parameter uses a name which has special meaning in Ifeffit: > dr >You must change this parameter name before attempting to fit. >One common example of this sort is a variable named "dr1", which >should be changed to something like "dr_1" or "drone"." > >The warning message doesn't make a great deal of sense as "dr" is a defined >parameter within Artemis. > >Running ifeffit-1.2.9-mac10.4_horae64pre_pkg on a Mac PPC G5 Dual 2GHz under >OS X 10.4.8. Presumably I'm doing something dumb (very much the novice EXAFS >is not my area). Have checked a number of the Ifeffit Archives, but so far >have not spotted a reference to this. > >Kind Regards >Craig Klauber > > > >__________________________________________________ >Craig Klauber >CSIRO Minerals >PO Box 90 >Bentley WA 6982 >AUSTRALIA >Ph: +61 8 9334 8060 >Fax: +61 8 9334 8001 >craig.klauber(a)csiro.au >CSIROTEL: 99 8060 >http://www-wf.minerals.csiro.au >__________________________________________________

1 1

N_ind
by m.bauer 10 Jan '07

10 Jan '07

good evening everybody, i just started exposing myself to the nyqvist-topic and even i might be on the risk of boring the specialists out there i have another question for my better understanding: if i fit my data in k-space without any fourier filtering and backtransforming etc. what value of /dr/ do i have to use when calculating the N_ind? i hope it is just that range in the r-space, which contains significant (or according to my structural model used reasonable) structural data, i.e. the range i would use if i would filter the data....!? thanks for your help, regards matthias -- Matthias Bauer Universität Stuttgart Institut für Physikalische Chemie Arbeitskreis Prof. Dr. H. Bertagnolli Pfaffenwaldring 55 70569 Stuttgart (Vaihingen) Telefon: (+49) 0711-685-64472 Fax: (+49) 0711-685-64443 E-Mail: m.bauer(a)ipc.uni-stuttgart.de homepage: http://www.ipc.uni-stuttgart.de/~matthias/index.htm

1 0

Problems with the >flatten< option in Athena
by Jens Kruse 10 Jan '07

10 Jan '07

Hi, I have a normalization problem with Athena. If I turn on the "flatten" option in the background removal section, Athena creates in some of the normalized spectra a step in the pre-edge range. How can I get rid of it? Thanks, jens

2 1

RE: [Ifeffit] Problems with the >flatten< option in Athena
by Kelly, Shelly D. 10 Jan '07

10 Jan '07

Hi Jens, You can try moving e0. E0 should be on the edge. Is E0 at the position of the step? You could also send us an example. Then we can help more directly. I'd guess that the step is caused by some background parameters that are set incorrectly. SK > -----Original Message----- > From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit- > bounces(a)millenia.cars.aps.anl.gov] On Behalf Of Jens Kruse > Sent: Wednesday, January 10, 2007 8:56 AM > To: ifeffit(a)millenia.cars.aps.anl.gov > Subject: [Ifeffit] Problems with the >flatten< option in Athena > > Hi, > > I have a normalization problem with Athena. If I turn on the "flatten" > option in the background removal section, Athena creates in some of the > normalized spectra a step in the pre-edge range. How can I get rid of > it? > > Thanks, > > jens > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

1 0

Re: [Ifeffit] R-factor uncertainty
by Scott Calvin 10 Jan '07

10 Jan '07

Hi Lisa, >At 07:23 AM 1/5/2007, you wrote: > >I have a question about the R factor: how can I decide if the >difference between the R factors of 2 fits is statistically >significant, i.e, how can I calculate the uncertainty which has to >be associated to the R factor? > As I understand it, you can't. The R-factor is not a proper statistical measure, as it doesn't incorporate any measure of data quality. That's the great weakness of this measure of quality-of-fit. It is also its strength, as estimating the uncertainty in EXAFS data is notoriously problematic. The complementary statistic is reduced chi-square. It does incorporate a measure of data quality. By default, ifeffit uses noise from high in the FT to estimate this. That's a reasonable idea, but can be problematic. It has been shown (by Matt and/or Shelly, as I recall), that there may in some cases be signal in the part of the FT ifeffit is using to estimate noise. There are also cases where the noise may not be "white," that is, the noise high in the FT may be a poor estimate of the noise low in the FT. Ifeffit does allow you to specify a value of the measurement uncertainty instead, so if you think you have a way of doing this, go ahead. What does all this mean in practice? It means, in my opinion, that the actual =value= of the reduced chi-square statistic is usually meaningless, unless you have a good way of coming up with the measurement uncertainty (for example, your sample may be so dilute that errors are dominated by counting statistics). But reduced chi-square is a great statistic for comparing two fits to a given set of data, particularly if the k-range, k-weighting, and k-window are the same for the two fits. For example, you can apply statistical tests of significance, if you'd like. The R-factor then provides the reality check that the fit is "good" at all. The R-factor isn't doing anything other than what you can see by looking at a graph, but is a nice shorthand for tables showing the results of many fits and similar applications. If there's a big R-factor (say, 0.20), the question of statistical significance isn't necessary to tell you that you haven't got a conclusive positive result: maybe the R-factor is big because the fitting model is lousy, or maybe it's big because the data quality is lousy, but either way the fit shouldn't be trusted. I'd also add that your eye tells you considerably more than the R-factor, because you can tell the character of the mismatch. Is it in the high part of the FT, low, or evenly throughout? Is the miss primarily in amplitude, or phase? I often find I choose a fit with an R-factor of 0.03 over one with 0.01, if, for example, the 0.03 reproduces qualitatively all the features in the data but has small errors in the amplitude of the peaks, while the 0.01 fits the first part of the spectrum perfectly but misses some peak altogether. Hope that helps... --Scott Calvin Sarah Lawrence College

4 5

RE: [Ifeffit] Is there a physical meaning to a negative SO2
by Kelly, Shelly D. 09 Jan '07

09 Jan '07

Hi Todd, One thing to try is to set s02 to a positive value and all the other variables to reasonable values and then look at the real or imaginary parts of the Fourier transform and also look at the chi(k) spectra. You should "see" the affect that Scott mentioned. Shelly > -----Original Message----- > From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit- > bounces(a)millenia.cars.aps.anl.gov] On Behalf Of Scott Calvin > Sent: Tuesday, January 09, 2007 10:27 AM > To: 'XAFS Analysis using Ifeffit' > Subject: Re: [Ifeffit] Is there a physical meaning to a negative SO2 > > Hi Todd, > > Your paragraph below is correct; i.e. you do not have a physically > realistic model. One common cause of a negative S02 is that the model > also is off by half an oscillation. After all, the negative S02 turns > the signal upside down, shifting it by half an oscillation can then > cause a rough (but spurious) alignment between model and data. > > In any case, the model needs work; depending on your system and > degree of prior knowledge, you might be assuming the wrong species of > scattering atom, for example. > > --Scott Calvin > Sarah Lawrence College > > At 10:41 AM 1/9/2007, Todd Luxton wrote: > >I am very new to XAFS analysis, I am wondering if there is a > >physical meaning to a negative value for SO2. Based on the XAFS > >equation I can't understand what the physical significance of a > >negative SO2 value would be, therefore I am assuming that my > >modeling results using Athena are not representative of a physically > >realistic model due to the negative value calculated fro SO2 or more > >specifically the amp variable in the guess set. Any insight would > >be greatly appreciated. > > > > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

1 0