I think that's pretty much perfect. Is there any reason why you can't
leave pdb.read flexible for those who would only use 1 nucleus type.
That way, scripts wouldn't need to be broken.
Alex
On 10/4/06, Edward d'Auvergne <edward@xxxxxxxxxxxxx
> wrote:Unfortunately this approach for setting the heteronucleus name won't
work. It is assumed in relax that the heteronucleus name will be the
same for each residue. That's a big mistake on my part! Back in
August 2004 I merged the user functions 'pdb()' and 'vectors()' into
the single user function 'pdb()'. This occurred at r1312 of the
0.3
versions of relax (http://svn.gna.org/viewcvs/relax/0.3/?rev=1387 vs
http://svn.gna.org/viewcvs/relax/0.3/?rev=1388
). For proteins when
either the backbone NH or backbone CH relaxation data is being
studied, there was no need for the two user functions. This obviously
isn't the case when studying RNA.
I have an elegant solution which should fix this issue. I first
propose to split the 'pdb()' user function back into the original two
user functions. However as they are related my idea is to create a
function class which contains both user functions. These two
functions could be called '
pdb.read()' and 'pdb.set_vectors()'.
The second change would be to add the two function arguments 'res_num'
and 'res_name' to the 'pdb.set_vectors()' user function. Then for
Alex's example you could use following lines in the script:
pdb.read(name, self.alex_pdb)
pdb.set_vectors(name, heteronuc='N1', proton='H1', res_name='G')
pdb.set_vectors(name, heteronuc='N3', proton='H3', res_name='U')
These changes break script compatibility,
i.e. a script written for
relax version 1.2.7 which uses the 'pdb()' user function will no
longer work with these changes. Therefore the changes must occur in
the next relax minor number - the 1.3 versions.
What do you think?
Edward
On 10/4/06, Alexandar Hansen <viochemist@xxxxxxxxx> wrote:
> Great! I'm glad the CSA should be easy. However, I realized another
> problem with multiple nuclei. How do we choose different PDB nuclei to form
> the bond? Again, i was thinking something along the lines of:
>
> Also, will this work in full analysis?
>
> # Load the PDB file.
> if not local_tm:
> if residue.name == 'G'
> pdb(name, self.alex_pdb, heteronuc='N1', proton='H1')
> if residue.name == 'U'
> pdb(name, self.alex_pdb, heteronuc='N3', proton='H3')
>
>
> self.alex_pdb is my pdb which I decided to define where I define
> local_tm/sphere/etc.
>
> Is this anywhere close to something that would work?
>
> Alex H.
>
>
>
>
>
> On 9/28/06, Edward d'Auvergne <
edward.dauvergne@xxxxxxxxx> wrote:
> > Unfortunately this approach won't work. You would need to create an
> > additional loop where you loop through the residues (in the future
> > maybe data sets) and set the value on a per residue basis. You would
> > need something like:
> >
> > value.set(name, 1.01 * 1e-10, 'bond_length')
> >
> > # Loop over the sequence.
> > for residue in
self.relax.data.res:
> > # Guanium.
> > if residue.name == 'G':
> > value.set(name,- 130 * 1e-6, 'csa',
> > res_num=residue.num, res_name=residue.name )
> >
> > # Uracil.
> > if residue.name
== 'U':
> > value.set(name, -100 * 1e-6, 'csa',
> > res_num=residue.num, res_name= residue.name)
> >
> >
> > That should do the job. However a much more powerful approach would
> > be to take this out of the hands of the user. This could be done by
> > modifying the 'value.set()' user function to set values based on the
> > residue name. Actually, I just checked the code - I implemented this
> > feature years ago!!! That simplifies things, all you need to do is
> > supply the residue name to the 'value.set()' function and it will set
> > the values based on the name. The solution is therefore extremely
> > basic:
> >
> > # Set the bond length.
> > value.set(name, 1.01 * 1e-10, 'bond_length')
> >
> > # Set the NH CSA values of the four bases.
> > value.set(name, - 130 * 1e-6, 'csa', res_name='G')
> > value.set(name, - 100 * 1e-6, 'csa', res_name='U')
> >
> > That's it!
> >
> > Edward
> >
> >
> >
> > On 9/29/06, Alexandar Hansen < viochemist@xxxxxxxxx> wrote:
> > > As I was running the full_analysis.py for an RNA data set of U and G
> data, I
> > > realized that it's trying to use the same CSA for each residue. Looking
> > > into the script, it would seem to be relatively easy to code the "set
> the
> > > bond length and CSA values" section in such a way that it chooses a
> > > different CSA value for the given residue types. Currently it's simply:
> > >
> > > value.set(name, 1.02 * 1e-10, 'bond_length')
> > > value.set
(name, -170 * 1e-6, 'csa')
> > >
> > > to modify this for RNA, could one edit it to say:
> > >
> > > value.set(name, 1.01 * 1e-10, 'bond_length')
> > > if residuename = G
> > > value.set(name, -130 * 1e-6, 'csa')
> > > else if residuename = U
> > > value.set(name, -100 * 1e-6, 'csa')
> > >
> > > Am I overtrivializing this, or should it be pretty straight forward?
> > >
> > >
> > > Alex Hansen
> > >
> > >
> > > _______________________________________________
> > > relax (
http://nmr-relax.com)
> > >
> > > This is the relax-users mailing list
> > > relax-users@xxxxxxx
> > >
> > > 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-users
> > >
> > >
> > >
> >
>
>
>
Re: Accounting for N1 and N3 CSA differences in RNA