mailRe: The handling of relaxation data within relax - a redesign might be necessary!


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

Header


Content

Posted by Sébastien Morin on February 17, 2009 - 23:39:
Please read below...


Edward d'Auvergne wrote:
On Tue, Feb 17, 2009 at 9:30 PM, Sébastien Morin
<sebastien.morin.1@xxxxxxxxx> wrote:
  
Hi,

Such a design integrating ALL kinds of data within relax would be very
useful to share data among the different analyses.
    

It would also make it easier to support new types of analysis, such as
relaxation dispersion.  I would limit this to simply relaxation data
though rather than all data, for example NOESY restraint data cannot
fit into this idea.


  
I don't see any problem with the design proposed. The only detail, of
course, will be to allow this design to evolve so new data can be stored
without another redesign. For example, if, in the future, the relaxation
dispersion code supports analysis of multiple temperature datasets,
there will need to be a way of storing these separately, as the
spectrometer tags won't suffice to store different 'R2eff' recorded at
the same spectrometer frequency, same delay T, same CPMG frequency, etc.
    

I would like to have a design that all new analysis types are designed
around and which will be sufficient for these analyses.  The best way
to do this would be to simply design it around the different types of
relaxation dispersion analyses.  I'm hoping that you can clarify the
issues with this analysis type.  It would be good to list, with
examples and possible ID strings, everything needed for relaxation
dispersion.  This includes the fitted Rex free R2 values - which can
be fed directly into a model-free analysis, etc.
  
For a CPMG relaxation dispersion analysis, one would need:


1.
Intensities
These intensities would be associated to a spectrometer frequency, to a
CPMG delay T, to a CPMG frequency (None in the case of the reference
spectra). Some of these intensities would be duplicated for error analysis.
From theses informations, the values of R2eff for a specific
spectrometer frequency and CPMG frequency would be extracted.


2.
R2eff
These could be extracted from intensities (see above) or could be
directly input into relax.
If directly input, they would be associated to a spectrometer frequency
as well as a CPMG frequency.


3.
Dispersion parameters
After extraction of R2eff values (and associated information),
dispersion curve fitting could proceed, yielding different parameters,
depending on the timescale chosen, for example.
In the fast exchange limit, these would include the exchange-free R2,
Rex and kex.
In the slow exchange limit, these would included the exchange-free R2
for site A (R2A), kA and dw.

Other informations could be input and/or extracted in the case of R1rho
relaxation dispersion. For example, such analysis could proceed from
measurement of exponential decays at different effective spin lock.
Hence, instead of just one intensity for each CPMG frequency (as in CPMG
relaxation dispersion), there would be multiple intensities (each
associated to a relaxation delay) for each spin lock field strength.
It's been a long time since I did R1rho relaxation dispersion, so I
could be confused, but you get the idea...


Is it the information you needed ?

Regards,


Séb  :)


For multiple temperatures, I don't think we need to design anything
special for it.  I would recommend simply having the data in separate
data pipes.  But if needs to go into the same data pipe (here would be
a future analysis type possibility), then these can be differentiated
by the user by giving them different ID strings, e.g. 'R2_303K',
'R2_308K', etc.  These can then be associated with different
temperatures with the temperature() user function (after
modification).  I think this simplicity of a single ID string, like
the single ID string per peak intensity list, would be the best way to
go.

Regards,

Edward

  


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





Related Messages


Powered by MHonArc, Updated Fri Feb 20 15:00:25 2009