Re: [Ifeffit] Very large exafs amplitude in collected data - cause unknown
On Wednesday, June 05, 2013 02:55:25 PM you wrote:
Hi,
Sorry about that, I wasn't sure what the best format would be for these forums. I have converted the data to a different format that should hopefully be more friendly.
This has data in the following columns;
1 = real time clock 2 = Mono angle (requested) 3 = Energy (eV) 4 = I0 5 = I1 6 = I2 7-9 = blank 10-44 - fluor channels (SCA) 45-79 - ICRs for the det elements
The weights are arbitrarily unity, and the dark currents were not recorded (assumed zero).
I have also attached an averaged file generated using average 2.0 if thats more useful for people.
Jason, You replaced one large, unweildy file format with another large, unwieldy file format. You should consider yourself fortunate that I have taken the time to bother with you. The folks on this mailing list, myself included, are volunteers. None of us get anything for offering time to answer these questions other than a sense of community spirit and community service. It is completely unreasonable that you have asked your question in a way that required lots of work simply to understand the question. Had you been a little more thoughtful and a little less unreasonably demanding of the time of volunteer help, you could have converted your data files into simple, 2-column files -- energy and mu(E) -- that would have been trivially easy for your volunteer to examine. Instead, you first sent the data in one basically inscrutable format, then in a second similarly unwieldy format. Awesome. Such a good use of my time. Please read this: http://bruceravel.github.io/demeter/pods/help.pod.html When you are done, please follow the link to the article by Raymond and Moen and read that. Now that I've had my rant, I'll address your question. Attached is your Au nanoparticle data overplotted with a spectrum measured on a gold foil. Clearly your data is awful and probably unsalvageable. Without knowing all the details of your measurement, it is very difficult to know what went wrong. Given that the oscillations in your data are commensurate with those in the gold foil, it is unlikely to be a monochromator problem or a problem with pressure variations in the I0 ionization chamber. I also don't think you had an egregious problem with sample preparation. Problems that fall under the rubric of sample inhomogeneity tend to damp the oscillations rather than enhance them. Also sample inhomogeneity tends to fail to normalize mono glitches away. You data, while problematic, don't seem to have that problem. My guess is that you have a problem of detector linearity, but not saturation of the Ge detector. Saturation (aka pile-up, dead-time) also serves to damp the oscillations. Perhaps there is some sort of coupling in the signal chain between the Ge detector and I0? I'm knd of running out of ideas here.... The bottom line is that this is the sort of problem that needs to be recognized and addressed while still at the synchrotron. I don't see what you can do to correct this after the fact in a way that would leave your data defensible for publication. The slim silver lining is that this teaches an important lesson about evaluating data quality as it is being measured. B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Methods Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel
Hi Jason, I didn't try to use the original data (and, like Bruce's rant, once I saw that it was a spec file with multiple scans [er file and with 100+ columns, I didn't even try). But from looking at the spectra Bruce posted, it's hard to see what the problem might be. It's hard to say that the data is clearly wrong. It does look a lot like Au foil, but with a much, much lower sigma2, or much higher energy resolution or mean-free-path or something else to increase the amplitude in a k-dependent way . It's hard to see how any measurement problem would give such an artifact, but we don't know a lot about how the measurements were made. Obviously, a clearer data file would be helpful, as would more information about the sample and measurements. What values do you get for sigma2? You said the values were not sensible, but you didn't say what that was. You also said the amplitude was "huge, up to 80 in some cases". I have no idea what that means... Was the sample cold? Do you have multiple measurements that show the same amplitude behavior? --Matt
Hi All, Well, this is certainly interesting. I had a chance to look at the data myself, and although I can't say if the results are meaningful, or useful, or even what you wanted, I don't see large amplitudes like Jason and Bruce report. A quick glance at the header of the files showed a list of column heading. Column 1 was energy. No I0, but, there was a counter, and everything else was DXP related so I guessed that was your ion chamber. DXP_Total caught my eye, and I'm guessing it sums the dxp## columns that follow. I loaded column 1 vs. (8/7) in Athena. I had to change all the groups to Au L3 edge, and I fixed the E0 to something sensible like 11923 (it's default position was somewhere after the white line). After changing the pre-edge range so it didn't end so close to the peak (-182 to -90) I merged them. k2 weighted graph attached. A quick first shell fit in Artemis gave me something like 15 Au neighbors at around the distance predicted in, http://prb.aps.org/abstract/PRB/v77/i7/e075432 The plot even looks kind of like their data. (Disclaimer: this was by no means a proper fit, but not bad for 2 minutes and a google search). So...It may not be as hopeless as you think. Without knowing anything about the samples or the experimental setup, you may still need to look into dead time correction, self-absorption correction, etc., and by all means look at each detector channel and make sure you're not summing in bad channels. I can't agree strongly enough with the need to look at the data as it comes in (it's a lesson I suspect many of us learned the hard way at some point), and Jason, welcome to the list. Dan Daniel Olive --- dolive@lbl.gov Postdoctoral Researcher University of California, Berkeley Nuclear Science Division Lawrence Berkeley National Laboratory 1 Cyclotron Road MS 70A1150, Room 70A-2205B Berkeley, CA 94720-8175
Hi Dan,
On Wed, Jun 5, 2013 at 1:18 PM, Daniel Olive
Hi All,
Well, this is certainly interesting. I had a chance to look at the data myself, and although I can't say if the results are meaningful, or useful, or even what you wanted, I don't see large amplitudes like Jason and Bruce report.
A quick glance at the header of the files showed a list of column heading. Column 1 was energy. No I0, but, there was a counter, and everything else was DXP related so I guessed that was your ion chamber. DXP_Total caught my eye, and I'm guessing it sums the dxp## columns that follow. I loaded column 1 vs. (8/7) in Athena. I had to change all the groups to Au L3 edge, and I fixed the E0 to something sensible like 11923 (it's default position was somewhere after the white line). After changing the pre-edge range so it didn't end so close to the peak (-182 to -90) I merged them. k2 weighted graph attached.
A quick first shell fit in Artemis gave me something like 15 Au neighbors at around the distance predicted in, http://prb.aps.org/abstract/PRB/v77/i7/e075432 The plot even looks kind of like their data. (Disclaimer: this was by no means a proper fit, but not bad for 2 minutes and a google search).
So...It may not be as hopeless as you think. Without knowing anything about the samples or the experimental setup, you may still need to look into dead time correction, self-absorption correction, etc., and by all means look at each detector channel and make sure you're not summing in bad channels. I can't agree strongly enough with the need to look at the data as it comes in (it's a lesson I suspect many of us learned the hard way at some point), and Jason, welcome to the list.
Dan
Daniel Olive --- dolive@lbl.gov Postdoctoral Researcher University of California, Berkeley
Nuclear Science Division Lawrence Berkeley National Laboratory 1 Cyclotron Road MS 70A1150, Room 70A-2205B Berkeley, CA 94720-8175
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Thanks for that. I think many of would be interested to know what the file really contains (there must be an I0 in there somewhere, no? but if you just add channels multiple times, shouldn't that normalize out? how would it be k-dependent?). It would be nice to straighten this out, if for no other reason than to demonstrate that exceedingly large and poorly documented data files can cause weird, difficult to diagnose problem, even for the people who originally collected the data. --Matt
participants (3)
-
Bruce Ravel -
Daniel Olive -
Matt Newville