RE: [Ifeffit] Re: Ifeffit Digest, Vol 22, Issue 1
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
Michel,
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?
Possibly. Some of the data is good and useful. The hard part isn't so much the conversion. There are a couple different formats of the Lytle data, but most of the conversion is easy (an ifeffit macro will usually do -- one is given in a FAQ). The hard part is deciding what the good data actually is. That part would require human intervention and better notes about what the data is. It might be doing, but would take some effort.
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...
I have at least two programs to split spec files into individual scans. That part is pretty easy. It's still sometimes a challenge to tell (at least in an automated way) what the columns are. In principle, this information is in the header of the spec file and could be auto-determined, which could probably mean you could automatically separate the energy scans from the slit scans. My simple scripts don't do that. I would imagine that someone at ESRF has dealt with this more completely, but I could find and most my scripts if there's an interest in them. --Matt
Dear all, Daresbury in the UK, produces the raw data in angle of mono steps/angle which is then merged, corrected for the monochromator and converted into eV and log (It/Io). Do I take it xmu coloumn refers to log (It/Io) for the data entry into Ifeffit? Regards William On Thu, 2 Dec 2004, SCHLEGEL Michel 177447 wrote:
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
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Hi, There are three aspects to this morning's thread that I'll comment on. (1) I won't disagree that XAS data should be presented to the beamline user in the form of signal as a function of energy. That should be considered a standard format for data presentation. That said, it is, apparently, less clear to me than to some others what Athena should and shouldn't do. Athena already has utilities for e.g. converting from keV to eV (a fairly trivial chore) and converting dispersive data measured as a function of pixel position into data as a function of energy (a fairly tricky chore). It's not clear to me that encoder to energy conversion is so very different from those. It'll be easy enough to ignore, if it really bugs you ;-) (2) I am uncomfortable with the phrase "the Athena test". I cannot comfortably be a part of any discussion of file standardization that has such an obvious conflict of interest built in from the get-go. (3) Supporting data harvested from SPEC files has long been on my list of things to do. A good, object-oriented interface to spec files built with perl would take a week or two of solid work to build and test properly. I am aware of many beamlines (a few at the ESRF for example, as well as any crystallography beamline that wants to pop off a quick absorption scan) that use SPEC, so that would be a useful thing to have -- not just for Athena but for anything in perl that wants to play with SPEC files. (A quick google search turns up nothing of the sort, sadly.) The issue of incompletely documented columns is, as Matt pointed out, a real one with SPEC files. However, it's not a problem unique to SPEC files. DND-CAT, for instance, produces files that have that problem in spades. (Well... the ones that Dave Barton keeps sending to me do...!) Dealing with non-obvious files is the reason that Athena's column-selection dialog replots the data every time you click one of the column buttons. This allows you to poke at an unclear file until you find some columns that make sense. 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 Bruce,
(1) I won't disagree that XAS data should be presented to the beamline user in the form of signal as a function of energy. That should be considered a standard format for data presentation. That said, it is, apparently, less clear to me than to some others what Athena should and shouldn't do. Athena already has utilities for e.g. converting from keV to eV (a fairly trivial chore) and converting dispersive data measured as a function of pixel position into data as a function of energy (a fairly tricky chore). It's not clear to me that encoder to energy conversion is so very different from those.
It'll be easy enough to ignore, if it really bugs you ;-)
I agree that converting mono steps to energy is like converting dispersive xafs pixels to energy. A solution is probably only needed for one or two beamlines, and any solution would probably be difficult to apply to data from other beamlines. Coming up with a templating system that can handle most ASCII data seems like it could be OK too. I don't know what to do about binary data. BTW, I believe sixpack does have support for several beamline-specific formats so that multi-element data can be automatically addedd together.
(2) I am uncomfortable with the phrase "the Athena test". I cannot comfortably be a part of any discussion of file standardization that has such an obvious conflict of interest built in from the get-go.
Would calling it 'The Ifeffit Test' be OK?. I'm comfortable with that and have no qualms about such a conflict of interest, and doubt an IXS group would do any better. If some other analysis program wants to link with ifeffit just to read data, they can. That makes this a reasonably well-defined standard with ready-to-use code freely available.
(3) Supporting data harvested from SPEC files has long been on my list of things to do. A good, object-oriented interface to spec files built with perl would take a week or two of solid work to build and test properly. I am aware of many beamlines (a few at the ESRF for example, as well as any crystallography beamline that wants to pop off a quick absorption scan) that use SPEC, so that would be a useful thing to have -- not just for Athena but for anything in perl that wants to play with SPEC files. (A quick google search turns up nothing of the sort, sadly.)
The code I have for reading spec files (some perl, a little more python, and some matlab from Tom Trainor) is at http://cars.uchicago.edu/ifeffit/specdata/ This wasn't meant for general release, so the documentation is non-existent, but it works for me. --Matt
Hi, I've never quite well understood why do theoretical phases and amplitudes seem to be dependent on the interatomic distance between the absorber and scatterer atoms. Shouldn't it only depend on the nature of the atoms involved? Nevertheless when trying to build theoretical references I'm always careful in choosing an appropriate distance. Otherwise the difference in phase shifts must be compensated at the expense of large E0 values. Could someone please shead more light on this subject? Thanks, Hugo Carabineiro PhD Student
On Monday 06 December 2004 08:36 am, Hugo Carabineiro wrote:
Hi,
I've never quite well understood why do theoretical phases and amplitudes seem to be dependent on the interatomic distance between the absorber and scatterer atoms. Shouldn't it only depend on the nature of the atoms involved? Nevertheless when trying to build theoretical references I'm always careful in choosing an appropriate distance. Otherwise the difference in phase shifts must be compensated at the expense of large E0 values. Could someone please shead more light on this subject?
Hi Hugo, That's good question. The photoelectron is a curved wave, not a plane wave. There are lots of references on this, but one useful and readable one is Rehr et al, J. Amer. Chem. Soc. v.113 (1991) p. 5135. If you look at Eq. 1 (and the cited references), you will see that there is a Hankel function involved in the computation of the scattering amplitude. This introduces the scattering distance into the equation. It turns out not to be a super sensitive dependence. In my experience, getting R wrong by a little bit can be compensated simply by the delta R shift in Ifeffit. But when R is vastly wrong (tenths of an angstrom), then you are correct in stating that some other phase portion of the fit might be used to compensate for the error. 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/
Thanks Bruce for unravelling this mistery... so quickly!
However you have referred particularly to the scattering amplitude
dependence on the interatomic distance. How about the phase shift, which
seems to depend strongly on the this variable?
Hugo
----- Original Message -----
From: "Bruce Ravel"
On Monday 06 December 2004 08:36 am, Hugo Carabineiro wrote:
Hi,
I've never quite well understood why do theoretical phases and amplitudes seem to be dependent on the interatomic distance between the absorber and scatterer atoms. Shouldn't it only depend on the nature of the atoms involved? Nevertheless when trying to build theoretical references I'm always careful in choosing an appropriate distance. Otherwise the difference in phase shifts must be compensated at the expense of large E0 values. Could someone please shead more light on this subject?
Hi Hugo,
That's good question. The photoelectron is a curved wave, not a plane wave. There are lots of references on this, but one useful and readable one is Rehr et al, J. Amer. Chem. Soc. v.113 (1991) p. 5135. If you look at Eq. 1 (and the cited references), you will see that there is a Hankel function involved in the computation of the scattering amplitude. This introduces the scattering distance into the equation.
It turns out not to be a super sensitive dependence. In my experience, getting R wrong by a little bit can be compensated simply by the delta R shift in Ifeffit. But when R is vastly wrong (tenths of an angstrom), then you are correct in stating that some other phase portion of the fit might be used to compensate for the error.
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/
On Monday 06 December 2004 09:42 am, Hugo Carabineiro wrote:
However you have referred particularly to the scattering amplitude dependence on the interatomic distance. How about the phase shift, which seems to depend strongly on the this variable?
The function that describes the scattering of the photoelectron is a *complex* function. It has an amplitude and a phase. For the WHOLE story: Rehr and Albers, Rev. Mod. Phys. v.72 #3 (2000) pp. 621-654. 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 (5)
-
Bruce Ravel -
Hugo Carabineiro -
Matt Newville -
SCHLEGEL Michel 177447 -
William Bisson