mailRe: Relaxation dispersion

Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]



Posted by Edward d'Auvergne on January 07, 2009 - 14:32:

I'll comment on all your points below.

On Tue, Jan 6, 2009 at 11:15 PM, Sébastien Morin
<sebastien.morin.1@xxxxxxxxx> wrote:
Hi Ed,

I started a branch (relax_disp) for implementation of relaxation
dispersion code.


The CPMG relaxation dispersion approach I presently work with is derived
from pulse sequences developped in Lewis Kay's laboratory (Hansen,
Vallurupalli & Kay, 2008, J.Phys.Chem.B 112: 5898-5904). The equation
for R2eff is as follows :

R2eff = ( 1 / T ) * Ln( Icpmg / Iref )

   where T is the constant time relaxation, Icpmg is the peak height
with CPMG, and Iref is the peak height without CPMG.

Then, from these R2eff (recorded with varying CPMG frequency), one can
fit relaxation dispersion and extract Rex, pa, pb, dw, tex, etc,
depending on the exchange regime (slow or fast)...

I wrote an interactive Mathematica notebook concerning the basics of
CPMG relaxation dispersion... You can find it at :


I've checked out the branch to watch the changes and downloaded the
Mathematica notebook.  This notebook seems quite useful to get an idea
of what happens to the relaxation dispersion profiles.

A few questions come to my mind, at this point.

How do we want to treat relaxation dispersion within relax ?

   Do we want to support both CPMG and R1rho relaxation dispersion
approaches ?
      -> I propose starting with CPMG.

I would suggest that too, but relax should be designed to handle both
from the start.  Maybe a user function such as relax_disp.exp_type()
could be used to specify which was collected.  If this is done then,
once relax is running with the CPMG data, adding support for R1rho may
only take one or two days of work adding a few additional functions to
the maths_fns code.  This will be very trivial and could be added by
anyone else interested in collecting this type of data.

   Do we want the code to work with peak heights or with calculated R2eff ?
       -> I propose starting with R2eff.

Here I suggest peak heights as this code already exists.  Hence
calculating R2eff can be one part of the minimisation function.  Or
maybe even calculate these as the first part of the
specific_fns.relax_disp.Relax_disp.minimise() function prior to
running the mathematical optimisation.  relax now has all the
infrastructure for peak heights, and therefore doing it this way makes
it significantly easier for the user while not being too much for the
implementor (a single small function will be sufficient).

In the future, R2eff may be input instead and this part skipped.
Maybe with the user function relax_disp.r2eff_read().

   Do we want to handle both slow- and fast-exchange ?
      -> I propose implementing both...

I think we should have everything (but not all done at once or all by
you).  First though, the simple fast-exchange formula.  But then
possibly all the formula in your Mathematica notebook.  These formula
are in reality mathematical models.  Therefore they should be
specified using a user function relax_disp.select_model() mimiking
model_free.select_model().  With this user function, each
model/equation can be implemented one by one after relax can already
successfully perform a relaxation dispersion analysis.

   Do we want to support the use of multiple field data simultaneously ?
      -> I propose yes, otherwise users will use some other in-house
programs which allow it...

Is multiple field strength data not essential for relaxation
dispersion?  The frq.set() user function I recently added to relax can
be used to specify which spectrometer frequency the peak intensities
come from.

   Do we want the code to be able to choose between slow- and
fast-exchange automatically, using some model selection criteria ?
      -> I propose yes, otherwise users will use some other in-house
programs which allow it...

This is statistical model selection which relax already implements.  I
have no idea which model selection technique will be best, but I would
guess AIC or BIC model selection will do a decent job.  Currently
(well, I haven't followed the relaxation dispersion literature too
closely) the way the model is selected is by using F-tests.  However
this is statistically flawed and should never, ever be done.
Statisticions would cringe if they saw what we in the NMR field do
here.  You just have to read the fine print on F-test to see why -
F-tests are only for testing the significance of models which are
"parametric restrictions" of each other!  That is definitely not the
case here!!!  Oh, the second problem is that hypothesis testing for
model selection was abandoned by this field in the 40's with only
likelihood ratio tests remaining today.  The reason is that you can
manipulate your tests to get the result you want - as has been done in
quite a number of model-free papers!

For implementing this - at the end - just run the model_selection()
user function and see which methods are missing from the specific_fns
code.  Only a few basic methods are required which have nothing to do
with model selection itself.

Let me know if you have a few ideas...

I have a few other small ideas, but I'll save these until later.




Séb  :)

Edward d'Auvergne wrote:

If you would like to implement this, please feel free.  I have so much
to do currently with relax that I won't have a chance to develop this
code for a long time.  This development will have to be done within a
branch because of the disruptive nature of the code.  I would suggest
that you do something similar to what you did with the consistency
testing code, by copying and modifying the reduced spectral density
mapping code.  However in this case, I would suggest copying and
modifying the relaxation curve-fitting code.  Don't be afraid of doing
anything, as I'll check all committed code as always and every change
can always be reverted.

For a start, I would develop a system test.  Having some limited
relaxation dispersion data, as peak heights, and the final results
will be required.  Published data could be useful for this, as then it
could be checked against the published results to make sure that the
code is correct.  Then you can store the input data into
'test_suite/shared_data', write a script called something like
'test_suite/system_tests/scripts/' which
implements a complete relaxation dispersion analysis (the script can
be later copied into 'sample_scripts/'), and then have code in the
system test checking if the final values are correct.

Then I would implement the necessary user functions.  Then the
specific_fns code.  And finally the maths_fns code with the relaxation
dispersion equations.  Finally debug until the system test passes.
This is the order that I develop the analyses in relax, and is the
best way to do this.  At all points you can copy and modify the
relaxation curve-fitting code as the concepts are quite similar.  So
similar in fact that implementing this analysis will not be too hard.
It might be nice if you had a protein system to run this on in the end
so you can publish the fact that you have implemented this code in
relax.  Well, assuming you decide to write this code.



On Tue, Dec 23, 2008 at 5:40 PM, Sébastien Morin
<sebastien.morin.1@xxxxxxxxx> wrote:


I have seen pass by the new pipe type 'relax_disp' a few weeks ago...
Since relaxation dispersion is in the list of techniques planned to be
supported in the future, I guess this is the first step toward

I would like to contribute to the development of this type of analysis.

What first steps could I do ? Should there be a new branch created to
start this ? Should some unit and system tests be written ? Should first
equations be introduced ?

Let me know what are your plans for this, Ed, and I'll try to help you
in any way you find useful.


Séb  :)

relax (

This is the relax-devel mailing list

To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at

Related Messages

Powered by MHonArc, Updated Thu Jan 08 06:00:16 2009