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/colu... 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@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/