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 > > http://salilab.org/imp/nightly/doc/html/kernel_examples.html > nup84 cg exampl 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? > > http://salilab.org/imp/nightly/doc/html/namespaceIMP_1_1atom.html#dc57f58d75... > 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.