mailRe: [Bug #7544] Incorrect nucleus names in results


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Alexandar Hansen on November 09, 2006 - 16:07:


On 11/9/06, Edward d'Auvergne <edward.dauvergne@xxxxxxxxx> wrote:
On 11/9/06, Alexandar Hansen <viochemist@xxxxxxxxx> wrote:
> Hi,
>
> So, I'm attempting this model_free.py fix, but I don't think it's as
> straightforward as you say.  My first thought was that the nucleus and pdb
> reads were only occuring once before the data loop and, since there's more
> than one nucleus/residue type, that should be included in the loop.
> Therefore, I copied this:
>
>         # Nucleus.
>             nucleus =
> self.relax.generic.nuclei.find_nucleus()
>
>         # PDB.
>             pdb = None
>             pdb_model = None
>             pdb_heteronuc = None
>             pdb_proton = None
>             if self.relax.data.pdb.has_key(self.run):
>                 pdb = self.relax.data.pdb[self.run].file_name
>                 pdb_model = self.relax.data.pdb [self.run].model
>                 pdb_heteronuc = self.relax.data.pdb[self.run].heteronuc
>                 pdb_proton = self.relax.data.pdb[self.run].proton
>
> Into the 'Loop over the sequence' but this didn't work.

You are on the right track.  However you only need to move the
'pdb_heteronuc' and 'pdb_proton' parts into the loop.  The 'pdb' file
and 'pdb_model' will be the same for all spins.  As for the 'nucleus'
values, these are not yet associated with specific spins.  The
'nuclei()' user function just sets one nucleus type for that run,
hence you can't currently analyse both carbon and nitrogen
simultaneously.  This will be fixed when the redesign of the relax
data model occurs.


>  I then manually
> read in my pdb and executed some pdb.read and pdb.vector commands to see
> what those lines are reading and confirmed that pdb.read() doesn't import
> anything about protons or heteronuclei.  Those are only assigned with the
> pdb.vectors() lines in full_analysis.py.  Now, you had suggested that, for
> me to read in multiple nuclei, I should load the pdb like this:
>
>                 # Load the PDB file.
>                 pdb.read(name,'my_pdb.pdb')
>                 pdb.vectors(name, heteronuc='N1', proton='H1', res_name='G')
>                 pdb.vectors(name, heteronuc='N3', proton='H3', res_name='U')
>
> While I believe this does read in the different vector types, it ulimately
> assignes heteronuc to 'N3' and proton to 'H3', writing over the first vector
> call.  Is there another place to pull the nucleus information from for a
> given row of input data?

Since I made those changes to the ' pdb.vectors()' user function to
allow different nuclei names, relax is now placing the information
into the residue specific data structure 'self.relax.data.res[run]'.
If you probe around in there you will find the proton and
heteronucleus names.


> Can I call the nucleus straight from the input
> data?  How can I be sure that pdb.vectors are matching everything up
> correctly in calculating relaxation?  Where is the list of pdb.vectors
> stored?  What information is stored with each pdb vector (orientation, bond
> length, nuclei, etc.)?  Sorry for all of the remedial questions.


As the proton and heteronucleus names are permanently stored in
'self.relax.data.res[run]', there is no need to read the values from
the input data.  If you probe around in there, you should see the
following data structures:

    proton
    heteronuc
    xh_vect

Great!  That made things pretty easy.  I reverted it back to the  repository version and made these changes:

Removed pdb_heteronuc = ... and pdb_proton = ... lines 4682-4683
Added this to the loop (at the new line 4700):

             # XH dipolar nuclei.
            if hasattr(data,'heteronuc'):
                pdb_heteronuc = data.heteronuc
                pdb_proton = data.proton

One thing I didn't understand was pdb.has_key(self.run).  What is that?  I'm guessing a flag of some sort that means "if a pdb was used, set value to X" or something along those lines.  Anyways, using the old "if ...has_key", it would still crash because it would come to residues (like A or C) which hadn't been assigned any heteronuclei.  So, I looked a few lines down and saw what seemed to be a self explanatory if statement that would work, ie "if hasattr(data,'heteronuc')"

Anyways, the sphere through ellipsoid results now have the correct heteronuclei and protons.


The 'xh_vect' is a unit vector parallel to the XH bond.  It's length
from the PDB is essentially meaningless as it is dependent on which
computer program generated the structure or added the protons later.

Doh!  I've had a look at the 1.3 line code and have realised that I
haven't placed the proton and heteronuc names into
'self.relax.data.res[run]'!  That will cause complications.  This will
be done before I even send this message.  Ok, it's done (see r2792 at
https://mail.gna.org/public/relax-commits/2006-11/msg00090.html).


> As for read_xxxxx, will this be read_columnar_results or one of the other
> read_columnar functions?  Thanks for all of the help.

The main driving function here is 'self.read_columnar_results()'.
Fixing up the reading code will be a little more difficult.  The best
option would probably be to modify the function 'self.
read_columnar_xh_vect()' to set the proton and heteronucleus names the
same way as the 'pdb.vectors()' user function does (by calling the
function 'self.relax.generic.pdb.vectors()').  This could be done by
mimicking the code already in that function.

The diff_model = 'final' also finished without error without me having to touch any of the read functions.  I was kindof hoping for another fatal error that could direct me to where you're talking about.  The 'final' results look alright, just the PDB_model, PDB_heteronuc and PDB_proton columns are filled with 'None'.

I'm starting to understand this python data structure type of programming.  Now I think I just need to figure out how much data is actually there and get used to the conventions you've set up in naming and using it.  I would _still_ like to fix or restrict certain diffusion parameters like one can do with ModelFree because of my limited data situation, but I'll wait and see how things go.


Alex

 

Thank you for helping to resolve these issues,

Edward


Related Messages


Powered by MHonArc, Updated Thu Nov 09 17:00:29 2006