Sorry about the delay there, I've been flat out with insane deadlines
and this will continue for the next two months! I'll barely be able
to write emails, so please bare with me. More below...
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.
This intensity data is covered by generic_fns/spectrum.py. The
resultant relaxation data - R2 = R2o + Rex', where R2o is the Rex free
R2 and Rex' is the residual Rex - and its metadata (CPMG frq, R1rho
strength, field strength, etc.) can then be stored in the ID
associated data structures (all dictionaries).
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.
Either calculated by fitting exponential curves, by taking the ratio
of a reference intensity vs. the measured intensity in a fixed tau_CP
period CPMG experiment, or by direct reading - all should be within
the same structures but with different ID tags.
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.
The exchange-free R2 and Rex are both relaxation rates, and should
probably go into these ID associated structures. We just need to
label them somehow to identify them, maybe in cdp.ri_label as is
currently done through the relax_data user function class. Their
names need to be in spin.params, but when unpacking dumped into for
example spin.relax_data['Rex'].
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...
This is easy. The first part is to run the intensities through relax
in the 'relax_fit' data pipes to fit exponentials. The fitted rate
needs to go into spin.relax_data['someID'] rather than spin.Rx as it
is now. Then the relax_data.copy() user function modified to do this:
relax_data.copy(pipe_from='exp1', pipe_to='disp', id_from='someID',
id_to='nu1')
This should then copy the data in spin.relax_data['someID'] to the
pipe_to data pipe ('relax_disp' type from 'relax_fit' type), along
with all the associated data in the pipe container.
Is it the information you needed ?
I hope so. Michael Funk told me there might be additional data
involved when you do R1rho and use trig functions to deconvolute the
offset effects. I'll look into this with Michael and continue
thinking about the design. As we will be ripping the heart out of
relax and then rebuilding it, I don't want to have to do this again at
a later date. So hopefully this design will be flexible enough to
handle everything published to do with relaxation data, and hopefully
any future developments as well.
Essentially this will have to go into its own branch as the changes
will hurt - everything will break. Or it can be done in stages with
it first implemented in the relax_disp branch, and then other analysis
types modified one after the other later on. This second option
allows you to keep moving forward Seb, without hurting the rest of
relax. What do you think is best?
Regards,
Edward
Re: The handling of relaxation data within relax - a redesign might be necessary!