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
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.
Thank you for helping to resolve these issues,
Edward
Re: [Bug #7544] Incorrect nucleus names in results