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 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
Re: The handling of relaxation data within relax - a redesign might be necessary!