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