Dave, I hope you do not mind that I am answering via the mailing list. The answer I have planned will be something that I think others will find useful. On Saturday 20 March 2004 03:30 pm, Barton, David (DG) wrote:
LOCATION OF Eo -Attached is two Ga XAFS spectra in an Athena file project. Look closely at the chosen Eo positions, I think you would agree that the choice is not near the maximum of the first derivative. These data sets both have a fairly reasonable signal/noise so that shouldn't be the source of the error.
Athena Report of Eo: --Ga_035 (10372.6 eV) and Ga_32-8 (10374.1 eV) ==Eo difference = 1.5 eV Using another plotting program: --Ga_035 (10373.3 eV) and Ga_32-8 (10373.5 eV) ==Eo difference = 0.2 eV
I understand that using the maximum in the first derivative is just an approximation of the Fermi Energy so the absolute value may not be so meaningful. However, we often use relative changes in the position of Eo as an indication of structural changes in our catalytic materials, so it would be helpful if Ifeffit was slightly more robust and precise in choosing the Eo value. Maybe you could consider incorporating a "smoothing" parameter which would help reduce the noise in the first derivative or some other algorithm which makes a better choice in the presence of some noise in the data.
For the sake of everyone else, I'll mention that the data Dave sent me had a slightly ambiguous e0 because the peaks in the first derivative were split into two peaks about the same height and about 1/2 volt apart. In one case, Ifeffit's algorithm for identifying the peak came up with a point a bit to the left of the two peaks and the other time a bit to the right. In neither case did Ifeffit (and hence Athena) pick one of the points at the peak. These choices to the left and right of the peaks result in the unphysically large energy separation that Dave is asking about. My initial response to questions like this is that it is rarely wise to blindly trust a program -- ours or anyone else's -- to do the right thing all the time. Just because we get one spectrum right or someone else gets another spectrum right is not sufficient reason to always trust any program. If you need it to be right, check and make sure it is right. That was fine advice -- possibly even tautological. But it wasn't very practical. The software really should work hard to get it right as often as possible. You suggest smoothing. That would probably work pretty well in this case. Indeed, it woul probably result in choosing a value between the two peaks. That's closer to correct and would probably at least be more reproducible between spectra than what happened with your data. But it would not be a panacea. Look at Zr 0+ some time. The maximum in the first derivative is more than 10 volts above the Fermi energy. Smoothing would not fix the "maximum in the first derivative" algorithm in that situation. So even with a more robust algorithm, you would be well served to be sceptical. I think the solution to your problem is to be a bit more hands-on and to make use of more of Athena's features. I typically use Athena's preprocessing features to handle ensembles of related data. The details of what you might do vary from situation to situation, but here is the outline: 1. Import one scan. This is going to be your "standard" against which the rest will be compared, so it should be a trustworthy one. Calibrate it by hand using the Calibration option in the Data menu. Play around with the background removal and FT parameters until you are reasonably happy with the data processing. 2. Use the "Open many files" option in the Files menu to import several more of the data files in that ensemble of related data files. 3. When the column selection dialog comes up, make sure that the columns are properly selected. Before hitting the OK button, hit the button that says "Set preprocessing parameters". This will expand the column selection dialog, showing a new menu and bunch of checkbuttons. 4. From the menu labeled "Standard" select the first data file that you read in. This will activate all the checkbuttons below. Now select the buttons for "Align to the standard" and "Set parameters to the standard". 5. Now click the OK button. As each data file is imported, it will be aligned and the parameters, including e0, the background parameters, and the FT parameters, will all be set to the values you settled on for the first data set. Magic!! If all went well, then each data set will be calibrated the same way as the first one and the background and FT parameters will be well set. The caveat is that the automated alignment does not always work well. A quick plot will let you know if it failed and you need to go back and align by hand. But with data that is low noise and similar, it tends to work ok. Depending on your data set and what you are aiming to do, you may need to do some variation of what I described above. Of course, a change in Ifeffit's algorithm might still be in order. But, in any case, I encourage you to resolve your e0 problems by explicitly examining one data file and using preprocessing to make the rest consistent with the first. HTH, B -- Bruce Ravel ----------------------------------- ravel@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/
Hi, The data in question also had energies that were not in strictly increasing order and had many visible spikes and dropouts in the mu(E) data that could certainly confuse the 'find the maximum of the first derivative' algorithm. But that being said, I could not reproduce Dave's problem, even with the data out of order and with dropouts. Exporting the xmu data, I got e0's that were very close to one another:
read_data(gadowee.xmu, group=gad, type=xmu) pre_edge(gad.energy, gad.xmu, find_e0=1) pre_edge: energy data appears out of order print e0 10374.0000
read_data(gamo.xmu, group=gam, type=xmu) pre_edge(gam.energy, gam.xmu, find_e0=1) pre_edge: energy data appears out of order print e0 10374.0900
I don't know why athena got to a different answer, or how to force it to re-determine e0. It would not be difficult to interpolate the data onto a very fine energy grid (say, 0.05eV) and do a multi-point derivative measurement to get a slightly more robust measure of E0. I'd stress the 'slightly' not because of the issue of stating that the max in the 1st derivative is the Fermi level, but because of the problem of dropouts and glitches, as the data here contains. --Matt PS: Whether the max of the 1st derivative is a measure of the Fermi energy is a whole other story.
Hmmm... I tried what you did, Matt. I exported mu(E) from Athena for both data groups and then did the e0 determination by hand. This happened: Ifeffit> read_data (gadowee.xmu, group=gad, type=xmu) Ifeffit> pre_edge(gad.energy, gad.xmu, find_e0=1) Ifeffit> print e0 10372.5980 Ifeffit> read_data (gam.xmu, group=gam, type=xmu) Ifeffit> pre_edge(gam.energy, gam.xmu, find_e0=1) Ifeffit> print e0 10374.0900 The first e0 value is different from the one you just reported and the same as Athena tells me. And I did not get the "out of order" message. I'm confused.
PS: Whether the max of the 1st derivative is a measure of the Fermi energy is a whole other story.
And how! B -- Bruce Ravel ----------------------------------- ravel@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/
participants (2)
-
Bruce Ravel
-
Matt Newville