[Ifeffit] 30 element detector data in athena

[Bruce Ravel]

On Tuesday 07 October 2003 11:49 am, Matt Newville wrote:
> Bruce,
>
> Yep, the column_label is restricted to 128 characters, which could
> be the limiting factor for many data files and is the limitation
> for the files I posted.
>
> What should be done??  text variables could be increased to 256
> characters, but that might not be enough.  A column lable of 2048
> would seem reasonable with 100+ columns (which is not out of the
> question).  Maybe having multiple text variables, $column_label_01,
> $column_label_02, etc.  I can't think of an easy solution that isn't
> icky...
>
> Ugh, Fortran.  It's really starting to be the main problem here.

Yup, no arguments that the lack of a malloc is a major headache.  I was 
thinking about this (among other things) during my 7 and a half hour drive up 
to NSLS today (traffic was awful!!!).  Unless I am mistaken, the major 
purpose of $column_label is to have a quick way of how many columns were just 
read by read_data() and what their names are.  That information is also 
reported by "show @group", but more reliably.  I wouldn't discourage you from 
somehow solving the $column_label problem within the constraints of Fortran, 
but I think the real solution is for Athena (and anyone else's program that 
relies on read_data() to, uhh..., read the data) is to issue a call to "show 
@group" and parse its response.

That will solve some of the problems with many-column data in Athena.  It will 
allow Athena to actually display all the column in the column selection 
dialog and allow the user to import as many columns as desired or to add up 
as many columns as desired on the fly as the data is imported.

However, two problems remain.

1.  Even with Athena parsing "show @group" to construct the column selection 
dialog, Athena and the Athena user will still be limited by the fact the 
Ifeffit is written in Fortran.  There are only so many (maybe less than 10) 
58-column data files that you can import before using up all memory available 
to Ifeffit.  If one wanted to process, say, 20 such files, one would probably 
have to use the trick of splitting them into groups, merging, then merging 
the merges.  That not bad, but it's not ideal either.

2.  Athena's column selection dialog is (in my wholly unbiased opinion ;-) 
very handy and easy to use for ion chamber data, i.e. for data with a small 
number of columns.  It will not be so user friendly when you have to dig 
through a grid that is 58 columns wide to construct your mu(E) data.  This 
brings me back to Carlo's comment that the user may be best served by 
preprocessing data before starting with Athena.

In any case, I will get this fix into the next release of Athena.  Between 
travel and an unusually high level of business at NRL, that may not happen 
until late October.

B 


-- 
 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/