[Ifeffit] 30 element detector data in athena

[Bruce Ravel]

On Monday 06 October 2003 06:35 pm, Matt Newville wrote:

> Oops, I was wrong earlier.  In fact, I usually use ifeffit to read
> files with many columns or beamline-specific software to add columns
> together.  But the file at
>   http://cars9.uchicago.edu/ifeffit/contrib/MED_FILES/mn_x.001

  <...snip...>

> But, Carlo is right: athena does not handle that many columns.  In
> fact, it shows "only" the first 35 in its data-column interface for
> these files, though the file viewer shows the full line length.  I
> suspect that Bruce never noticed this.

To the contrary, I most certainly have.  What I haven't noticed, up
until this week, was much complaint about how Athena handles
multi-column data.

Except for a few special situations, Athena relies entirely upon two
aspects of Ifeffit to read in data and construct the data import
dialog, i.e. this thing:
  
http://leonardo.phys.washington.edu/~ravel/software/exafs/images/athena/columns.png

For almost all data files, Athena uses ifeffit's read_data()
function.  read_data() sets a scalar called $column_label.  Athena
parses the contents of this scalar to determine what the columns are.
The grid of columns presented in the file import dialog is construsted
from this.  There is no hard limit to how many columns Athena is
willing to present, however it will not present any columns not
reported in $column_label.

Try reading the mn_x.001 file that Matt put on his web site.  I concur
that ifeffit reads in all the columns.  What it does not do is report
all the columns in the $column_label scalar.  And the only reason that
Athena reads as many columns as it does is because the mn_x.001 file
has nice short column lables, like D1 and D17.  If your column lables
were, say, "my_favorite_column_label" and
"my_second_favorite_column_label", the space in $column_label would be
used up with far fewer columns.

So, the obvious solution is for Athena to ignore the $column_label
scalar (which seems not to be serving its purpose) and instead to
parse the output of "show @group" for the newly read group.  The other
solution is for Matt to allow for a much longer string to be placed in
$column_label.

However, it seems to me that a bit of preprocessing, as Carlo does, is
still a good idea.  If the many-column data file has a well-known
structure, then a few lines of specialized python (or perl or VBScript
or whatever) will be an easier way to handle dozens of columns than
Athena's column import dialog.  This is particularly true if you need
to do deadtime correction, which Athena still does not handle for you.

B

P.S.  Of course, none of this discussion addresses the original
complain, which was Athena barfing for a particular file.  I would
still like to see that file.


-- 
 Bruce Ravel  ----------------------------------- ravel at phys.washington.edu
 Code 6134, Building 3, Room 222
 Naval Research Laboratory                          phone: (1) 202 767 5947
 Washington DC 20375, USA                             fax: (1) 202 767 1697

 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/