Like Daniel, I will leave the EM-specific parts to one of our EM people...
On 7/19/10 7:14 AM, Benjamin SCHWARZ wrote:
1.) As a first remark concerning this script, the module IMP.algebra is
used throughout the script, though never imported. Funnily, it puzzles
my PyDev plugin but does not appear to lead to execution problems.
Python has a global dictionary called sys.modules which lists all
modules that have been loaded. So once you've loaded a module, you can
use it for the rest of the lifetime of the interpreter. While
IMP.algebra isn't loaded in the script itself, it is loaded by one of
the modules that the script loads. I agree it would be clearer if the
script loaded the module itself though.
3.) I don't fully understand the way objects share elements, and what
happens when these elements are moved.
For instance, the three objects :
line 19 : mh=IMP.atom.read_pdb(IMP.em.get_example_path("input.pdb"),m,sel)
line 24 : ps= IMP.Particles(IMP.core.get_leaves(mh))
line 58 : prot_rb = IMP.atom.setup_as_rigid_body(mh)
seem to share atoms
A better way of thinking about it would be to say that they all share
the same set of IMP Particles (roughly speaking). All of the information
about the system is stored in Particles. But you can apply decorators to
particles to treat them in different ways. So here 'ps' is a flat list
of all of the atoms in the system, as Particles. 'mh' is a Hierarchy
decorator - it points to the same set of atoms, but as a hierarchy of
atoms, residues, chains, proteins etc. rather than a flat list.
'prot_rb' is a rigid body that again points to the same set of atoms but
treats them as a rigid body.
5.) The signature is not the same for function
IMP::em::local_rigid_fitting in the documentation and in the script.
In the documentation, it has a ( FittingSolutions & /fr) /argument
whereas, according to the script, this in fact seems to be the return type