Re: Multiple field relaxation dispersion data handling -- June 19, 2009

Hi Ed,

Thank you for the answer.

I will try to have a look at this during the summer, but I may miss timeas my little daughter Alexia was just born last Tuesday and, as newparents, we are facing many new challenges...

Anyway, when I have time, I know this has to go into a branch to followthe guidelines in your post at:


    https://mail.gna.org/public/relax-devel/2009-02/msg00009.html

(Message-id:<7f080ed10902170945q744a8328x8bc6233131e5d6d3@xxxxxxxxxxxxxx>)


Cheers and good luck for the talk at Euromar,


Séb  :)





Edward d'Auvergne wrote:

Hi,

Sorry for the delays responding.  I have to apologise as I will have
really no time in the next three weeks to answer questions.  I am very
busy at the moment developing a new NMR dynamics theory using RDCs for
a talk that I will give at the Euromar conference at the start of
July.  After this conference will I be able to return to normality and
answer questions and research and develop the concepts needed for
moving relax forward on all fronts.  In the mean time, you may see
some very strange code go into relax.

As for your specific queries about relaxation dispersion, there is a
post I wrote a while ago detailing what is necessary to handle this
type of relaxation data (as well as all relaxation data).  That is to
change how it is stored in the spin containers, converting the rates
to a single dictionary-type object.  Then the fancy structures for
standard relaxation for model-free, J(w) mapping, etc. - the remap
tables, frq, frq_labels, etc. - can be eliminated.  The key of the
dictionary will then match dictionary objects in the top level of the
data pipe where all associated information can be stored, i.e.
frequency, labels, v_cpmg, lock power, etc.  This will need to be in a
new branch just for redesigning the relaxation data storage, as it
will break almost all of relax from the start.  Feel free to have a go
at this - it doesn't matter if you don't get it right at the start if
it's in a branch!

Cheers,

Edward



On Wed, Jun 3, 2009 at 9:10 PM, Sébastien
Morin<sebastien.morin.1@xxxxxxxxx> wrote:

Hi,

I am currently trying to do some work on the relaxation dispersion
branch which has been on idle mode for somehow a long time...

Executing the system tests for relaxation dispersion, one of the current
problems concerns the way multiple field data is handled. It is now
having troubles at the very beginning, i.e. data input stage. This could
be bypassed and a single magnetic implementation be created, but I would
prefer implementing relaxation dispersion directly with multiple field
facilities since it is known that multiple field data is a pre-requisite
for reliable extraction of dynamics information from relaxation
dispersion experiments.

Ok.

So, the way I started to implement it was that peak amplitudes would be
first read into relax for all fields and R2eff would be extracted for
these respective fields. Hence, the following commands would be issued
(as in the system test script:
'test_suite/system_tests/scripts/relax_disp_cpmg_fast.py'):

======================================
import sys

# Create the data pipe.
pipe.create('rex', 'relax_disp')

# The path to the data files.
data_path_1 = sys.path[-1] +
'/test_suite/shared_data/curve_fitting_disp/Hansen/500_MHz'
data_path_2 = sys.path[-1] +
'/test_suite/shared_data/curve_fitting_disp/Hansen/800_MHz'

# Load the sequence.
sequence.read('fake_sequence.in', dir=sys.path[-1] +
'/test_suite/shared_data/curve_fitting_disp/Hansen')

# Name the spins so they can be matched to the assignments.
spin.name(name='N')

# Set the relaxation dispersion experiment type.
relax_disp.exp_type('cpmg')

# Set the relaxation dispersion curve type.
relax_disp.select_model('fast')

# Relaxation dispersion magnetic field (in Hz).
frq.set(id='500', frq=500.0 * 1e6)
frq.set(id='800', frq=800.0 * 1e6)

# Spectrum names.
names = ['reference.in_sparky',  '66.667.in_sparky', '1000.in_sparky',
'133.33.in_sparky', '933.33.in_sparky', '200.in_sparky',
'866.67.in_sparky', '266.67.in_sparky', '800.in_sparky',
'333.33.in_sparky', '733.33.in_sparky', '400.in_sparky',
'666.67.in_sparky', '466.67.in_sparky',    '600.in_sparky',
'533.33.in_sparky', '133.33.in.bis_sparky', '933.33.in.bis_sparky',
'533.33.in.bis_sparky']

# Relaxation dispersion CPMG constant time delay T (in s).
relax_disp.cpmg_delayT(id='500', delayT=0.030)
relax_disp.cpmg_delayT(id='800', delayT=0.030)

# Relaxation dispersion CPMG frequencies (in Hz).
cpmg_frq = [None, 66.667, 1000, 133.33, 933.33, 200, 866.67, 266.67,
800, 333.33, 733.33, 400, 666.67, 466.67, 600, 533.33, 133.33, 933.33,
533.33]

# Loop over the spectra.
for i in xrange(len(names)):
   # Load the peak intensities.
   spectrum.read_intensities(file=names[i], dir=data_path_1,
spectrum_id=names[i], int_method='height')
   spectrum.read_intensities(file=names[i], dir=data_path_2,
spectrum_id=names[i], int_method='height')
======================================


However, the script crashes at this point where the second magnetic
field data are read into relax. It crashes because the names of the
spectra are the same for both magnetic fields:

======================================
 File
"/home/semor/pse-4/collaborations/relax/relax-1.3--relax_disp/test_suite/system_tests/scripts/relax_disp_cpmg_fast.py",
line 83, in <module>
   spectrum.read_intensities(file=names[i], dir=data_path_2,
spectrum_id=names[i], int_method='height')
 File
"/home/semor/pse-4/collaborations/relax/relax-1.3--relax_disp/prompt/spectrum.py",
line 493, in read_intensities
   spectrum.read(file=file, dir=dir, spectrum_id=spectrum_id,
heteronuc=heteronuc, proton=proton, int_col=int_col,
int_method=int_method, mol_name_col=mol_name_col,
res_num_col=res_num_col, res_name_col=res_name_col,
spin_num_col=spin_num_col, spin_name_col=spin_name_col, sep=sep,
ncproc=ncproc)
 File
"/home/semor/pse-4/collaborations/relax/relax-1.3--relax_disp/generic_fns/spectrum.py",
line 831, in read
   raise RelaxError, "The spectrum identification string '%s' already
exists." % spectrum_id
RelaxError: RelaxError: The spectrum identification string
'reference.in_sparky' already exists.
======================================


So what should be done to avoid this ?

Should a magnetic field variable (something like 'frq') be added to the
spectrum.read_intensities() function in order for it to treat the
different magnetic field data separately ? This might be much
unnecessary work...

Should a loop be inserted in order to extract R2eff values from peak
intensities at one magnetic field at a time, before storing these
informations and, finally, doing the multiple field curve fitting of
relaxation dispersion ? I guess this would be the best option...

Should the complete approach be changed ?

Any suggestion ?


Séb  :)

--
Sébastien Morin
PhD Student
S. Gagné NMR Laboratory
Université Laval & PROTEO
Québec, Canada


_______________________________________________
relax (http://nmr-relax.com)

This is the relax-devel mailing list
relax-devel@xxxxxxx

To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel



--
Sébastien Morin
PhD Student
S. Gagné NMR Laboratory
Université Laval & PROTEO
Québec, Canada

Re: Multiple field relaxation dispersion data handling

Header

Content

Related Messages