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.
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
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.
III. Concerning the analysis part of the example :
1. The last argument of :
embed= IMP.statistics.ConfigurationSetXYZEmbedding(cs,
IMP.container.ListSingletonContainer(IMP.atom.get_leaves(all)), True)
is not documented.
Even though the name of the variable "bool align=false" is quite suggestive, I have an issue to guess the type of alignment that is considered here. Maybe a simple question can help to leverage my problem : Let's say I have two configurations that can be derived from one another through a simple rotation°translation; does setting this parameter to true help me to have the same embedding for each conformations, and hence classify both in the same cluster ?
It is whether rigid alignment is performed. Currently, this alignment is against the first configuration, which may not be the best option. I'll add a note to the docs.
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
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 ?
2. Are there any IMP functionalities to perform configurations or model alignments ?
Thanks for your precious help
--Ben