[Ifeffit] Re: Ifeffit Digest, Vol 22, Issue 1

[Matt Newville]

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