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