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

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