On Jun 24, 2011, at 5:04 AM, Benjamin SCHWARZ wrote: Hi Daniel, and thanks for the answers.
It is supposed to apply the simplest restraint it can based on what is passed. That is, one of: - distance restraint - kclosepairspairscore based restraint - connected pair container with distance pair score - connectivity restraint
I think I got the technical aspect of the function, but I am still puzzled with the concrete interpretations :)
Consider we have a coarse representation of a protein as a succession of 4 bead-domains, obtained through create_protein() with the provided indexes of the domain limits [0,100,200,320,456]. Somehow I'd like the connectivity to be enforced only between the successive domains… And I have the feeling this is not what is achieved in the nup84 cg example. Here, atom.create_connectivity_restraint() is called on a list of selection objects each resulting in a single particle, hence the usage of a ConnectedPairContainer, whose effect is to create a connection tree (?)… And basically, I have to confess I didn't really understand this specific container behavior neither from the documentation, nor from its code.
If you just want each successive pair to be connected, just add a distance restraint for each successive pair. You can do this in various ways, probably the simplest of which is to list the pairs and create a pairs restraint with that list of pairs and a HarmonicSphereDistancePairScore with a distance of 0. 3. Nothing very important, just a bit noisy/confusing : in create_protein() sub-function, the leaves variable leaves= IMP.atom.get_leaves(h) is never used… So why not just stripping it ?
I don't see that. Where is it?
kernel/src/nup84_cg line 28
Indeed, thanks. I'm not sure how I missed that.
4. minor bug in the documentation : some occurrences of create_connectivity_restraint() have no mentioned return type.
Where do you see this?
for instance, the first occurrence of create_connectivity_restraint reads Restraint* create_connectivity_restraint
(
const Selections &
s,
double
x0,
double
k
)
and the next one : IMP::atom::create_connectivity_restraint
(
const Selections &
s,
double
k
)
The same behavior seem to happen for each polymorphic function.
Odd, Thanks for pointing it out. I'll look in to it. Thanks.
OK… Let me try to put it right : 1. With align set to True, prior to their embbeding in dimension 3N, all configurations (comprising N particles in dimension 3) are firstly aligned on configuration0. 2. I guess the alignment is "merely" an RMSD minimization
Yes, rigid, RMSD minimization.
And add a few questions : 1. Based on my experiments it seems this alignment does not impact the configurations, I mean the rigid transformations is only applied to the embeddings and not to the configurations themselves. Correct ? Is there a way to retrieve the applied transformations, or a way to have them applied to the configurations too ?
Good point. I'll add a method to get them back out. 2. Are there any IMP functionalities to perform configurations or model alignments ?
There is functionality to perform alignment on sets of particles and points: get_transformation_aligning_first_to_second. For technical reasons, it is in IMP.core when using python and IMP.algebra when using C++. I'll bet there is a way I can insert the python functions into IMP.algebra so that it is symmetric. I'll look in to that. |