On Thu, Dec 4, 2008 at 4:00 AM, Sébastien Morin
<sebastien.morin.1@xxxxxxxxx> wrote:
Hi,
I've written the code for the reading of the generic intensity file as
formatted in "test_suite/shared_data/peak_lists/generic_intensity.txt"
(revisions 8118 to 8124).
The code now handles a file with the following format :
mol_name res_num res_name spin_num spin_name proton
intensity_1 ... intensity_n
The number of intensities input is automatically calculated and should
match the number of delays given as input in the used script.
Ok... This is less versatile than proposed in "prompt/spectrum.py" (line
370 and following). However, this is much easier to script and allows
the use of less coding to load the file (more friendly to the user)...
In fact, no "int_col" argument must be given and the file must be loaded
only once to be read entirely...
So... Should we think about making this 'generic' file format even more
'generic' (as suggested in "prompt/spectrum.py", line 370 and following)
or is the current 'generic' format suitable and enough to allow users to
easily input their data ?
I'm not sure if this would be the best way, or only way, for the NOE,
relaxation dispersion data, or any other type of analysis implemented
in the future. As you ask, it would be useful to implement the
int_col arg to allow for it to be a list (one that is exactly the same
size as the spectrum_ids list) rather than automatically loading all
of the generic formatted file. This will also allow a user to pull
out and use a single column from the file, and will give flexibility
for the user to label their spectra differently from what is in the
file. Oh, note that when loading peak intensities, there should be no
association with relaxation times to allow peak intensities to be
separated from the R1 and R2. Just think of using this code for the
NOE as well.
This doesn't mean that we should loose the ability of the automatic
reading of the file. I think that this could be allowed if both the
int_col and spectrum_ids args are set to None. Or if spectrum_ids is
supplied, it should match the number of intensity columns exactly
(here this lets the user name the spectra as they wish). All of these
ideas could be implemented as separate system tests. But for all of
this flexibility, print outs will be very useful. I suggest minimally
printing the list of spectrum ids, either from the user function arg
or as read from the header of the generic file. Also any information
the automatic reading does could be printed as well to give the user
feedback and to help them if something fails.
Regards,
Edward
Re: Generic intensity file - more or less generic ?