[prev in list] [next in list] [prev in thread] [next in thread] 

List:       relax-devel
Subject:    Re: Fast spectral density mapping
From:       "Edward d'Auvergne" <edward.dauvergne () domain ! hid>
Date:       2007-11-10 11:59:18
Message-ID: 7f080ed10711100359s2ef3e984p18efd3c3abea8904 () domain ! hid
[Download RAW message or body]

Hi,

>From memory I think this was mentioned somewhere else here before (or
on the relax-users mailing list).  If you would like to use this
approach and at the same time contribute the code to the relax project
(possibly for personal citation reasons :), you are most welcome.  If
it fits nicely into relax and has something to do with molecular
dynamics, it is quite likely to be incorporated.  But before this is
done, maybe it would be better to have the consistency test code
completed and placed into the 1.2 and 1.3 lines.

There are two separate and very different issues which need to be
addressed with the addition of a new feature such as this.  These are
the UI design and the implementation of the code within relax.  The UI
design is most important and is what a user sees of relax.  How the
code underneath this is designed is of no interest to the user.  So
for something like this, although there are many different
simplications to the original Peng and Wagner spectral density mapping
these are all independent.  So I would suggest that a different run
type (relax-1.2 speak) or data pipe type (relax-1.3+ speak) is created
for each.  These different types of analysis, although they can be
compared, are not combined.  So from the user perspective, you select
the analysis type at the start and you end up with results files for
that type.  If new user functions are required, these can be designed
as they are needed.

For the implementation in code, many parts of the spectral density
mapping code can be reused.  This is the where the power of the Python
classes and specifically inheritance comes into play.  All the common
functions/methods are placed into a base class and the specifics
implemented in classes derived from that base class.  I would suggest
this for the code in 'specific_fns/'.

Finally, a feature like this should go into the 1.3 line and not the 1.2 line.

Cheers,

Edward



On Nov 9, 2007 8:00 PM, Sebastien Morin <sebastien.morin.1@domain.hid> wrote:
> Hi
>
> A few months ago, I read a paper proposing a new approach for spectral
> density mapping : fast spectral density mapping.
>
> ==================================================================
> Ropars et al. (2007) JBNMR, 37:159-177.
> Unraveling protein dynamics through fast spectral density mapping
> ==================================================================
>
> This approach yields n + 2 spectral densities when measuring n + 2
> relaxation parameters, while the standard reduced spectral density
> mapping needs 3n measurements to yield 2n + 1 spectral densities.
>
> The new approach assumes that the high frequency approximation is valid,
> that is a single J(wH) is equivalent to different J(wH), for example
> J(wH) = J(500 MHz) = J(600 MHz) = J(750 MHz) = J(800 MHz)...
>
> The two approaches need 3 relaxation rates to yield J(0), J(wN) and
> J(wH). However, if one wants :
>
> J(0), J(wN1), J(wH1), J(wN2), J(wH2)
>
>   fSDM :  4 measurements needed (field 1 : R1, R2, NOE ; field 2 : R1)
>   rSDM :  6 measurements needed (field 1 : R1, R2, NOE ; field 2 : R1,
> R2, NOE)
>
> J(0), J(wN1), J(wH1), J(wN2), J(wH2), J(wN3), J(wH3)
>
>   fSDM :  5 measurements needed (field 1 : R1, R2, NOE ; field 2 : R1 ;
> field 3 : R1)
>   rSDM :  9 measurements needed (field 1 : R1, R2, NOE ; field 2 : R1,
> R2, NOE ; field 3 : R1, R2, NOE)
>
> J(0), J(wN1), J(wH1), J(wN2), J(wH2), J(wN3), J(wH3), J(wN4), J(wH4)
>
>   fSDM :  6 measurements needed (field 1 : R1, R2, NOE ; field 2 : R1 ;
> field 3 : R1 ; field 4 : R1)
>   rSDM : 12 measurements needed (field 1 : R1, R2, NOE ; field 2 : R1,
> R2, NOE ; field 3 : R1, R2, NOE ; field 4 : R1, R2, NOE)
>
> Thus, only R1 needs to be acquired at different fields with R2 and NOE
> only needed at one field with preference for a R2 measured at the lowest
> field to minimize possible exchange contributions.
>
> As as can be seen, the requirements for data acquisition are much
> smaller and this approach could eventually be used by some people.
>
> Thus, should this approach be integrated into relax ?
>
> If yes, how should it be integrated ? Should all the different
> approaches to reduced spectral density mapping (the one actually
> available, the multiple field approach, the fSDM, and any other) be
> merged together and a flag specified by the user to choose between the
> different methods ?
>
> Cheers
>
>
> Sébastien  :)
>
> --
> Sebastien Morin
> Etudiant au PhD en biochimie
> Laboratoire de resonance magnetique nucleaire
> Dr Stephane Gagne
> CREFSIP (Universite Laval, Quebec, CANADA)
> 1-418-656-2131 #4530
>
>
>
> _______________________________________________
> relax (http://nmr-relax.com)
>
> This is the relax-devel mailing list
> relax-devel@domain.hid
>
> 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
>


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic