> 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')"
The data structure 'self.relax.data.pdb' is what is known as a
dictionary type. A dictionary in other languages may be known as a
map, hash, dictionary, finite map, or lookup table (from
http://en.wikipedia.org/wiki/Associative_array). As an asside, it's
not a standard dictionary but a object with dictionary like properties
which means we can do fancy things with it (don't worry about that
now). The keys of this dictionary are the run names and the function
'self.relax.data.pdb.has_key(self.run)' will return true if the given
run is in the data structure. This statement is necessary in case a
PDB file has not been loaded. I hope that wasn't too confusing.
The hasattr() function is the one you need.
> 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'.
There won't be a fatal error because the results file contains the XH
unit vector and the 'heteronuc' and 'proton' values are only used to
calculate this vector. Hence when you read the results file, the
'heteronuc' and 'proton' aren't used for anything. We should have
these continually stored, written, and reloaded though because they
could be useful for selecting certain spins in the future.
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.
Python itself is very simple to learn as far a languages go, and its
data structures are very powerful tools. You can easily probe what is
in 'self.relax.data' from the prompt by typing 'self.relax.data'. All
the objects are special in that they have been modified to print out
useful info about that structure and how to access its elements.
As for fixing parameters, that could be quite complicated. I see two
ways of doing this, both of which will require a decent investment of
time. The first is messy and not ideal - design new and multiple sets
of model-free spectral density calculating functions, one for each
parameter fixed. The second option is probably the route which should
be taken. If you look at professional optimisation packages/software,
the ability to hold the parameter fixed is built into the optimisation
algorithms themselves. I never investigated this route because of the
time it would have required. I also don't know the mathematical
algorithm required to do this or whether it will apply to all
optimisation algorithms successfully. This will require research
involving mathematical optimisation books from a maths library (which
is what I did when I implemented all the optimisation algorithms!).
Edward
Re: [Bug #7544] Incorrect nucleus names in results