salilab / pmi

Python Modeling Interface
https://integrativemodeling.org/nightly/doc/ref/namespaceIMP_1_1pmi.html
11 stars 11 forks source link

Gaussian particles incorrectly placed by shuffle_configuration() #237

Closed benmwebb closed 6 years ago

benmwebb commented 6 years ago

As reported on IMP-users, Gaussian-decorated flexible beads are incorrectly placed by IMP.pmi.tools.shuffle_configuration using a bounding box (they are placed outside of the box):

The problem is coming when I set a bounding box to shuffle inside. The bounding box is offset from the origin, drawn to enclose the coordinates of a cryoEM structure which contains some already solved fixed-position rigid bead models. The model also contains rigid bodies and flexible beads. The flexible beads are all included as NonRigidMembers of the rigid bodies, as this seems to be the only way to allow Gaussian particles to be set on flexible beads. When the beads are shuffled, it seems to use the local x,y,z coordinates with the random bounding box translation, and as a result, the flexible beads do not end up anywhere near the global bounding box.

cgreenberg commented 6 years ago

I'm surprised this is possible. Gaussians are supposed to have the same center as their underlying XYZ. This may explain the occasional mysterious shuffle problem, though.

benmwebb commented 6 years ago

The (somewhat bizarre) code in IMP.pmi.tools.shuffle_configuration appears to be setting the local coordinates of the nonrigid member, but it probably needs to set the reference frame too, since Gaussians are also rigid bodies.

benmwebb commented 6 years ago

@iecheverria perhaps you could clarify what's going on here (you appear to have written the bounding box code)? I would assume the purpose of this function is to end up with all the particles distributed within the bounding box, but it doesn't seem to be doing that, at least not for nonrigid members. Instead, they get placed inside a corresponding bounding box in local coordinates, meaning that their global coordinates are nowhere near the original bounding box. Is this intentional? The corresponding test is testing for local coordinates rather than global coordinates, which makes me think it is, but I can't think of a reason why you'd want that to happen.

@cgreenberg can you also explain why you used FloatKey(4) through FloatKey(6) for the coordinates, rather than simply RigidBodyMember::get_internal_coordinates() ? The only difference I can see is that using the float keys directly avoids clearing the rigid body particle cache.

iecheverria commented 6 years ago

@benmwebb I will check what is going on. Certainly, it is not desired nor expected for the bead particles or Gaussians to end outside the bounding box.

cgreenberg commented 6 years ago

@benmwebb I don't recall. If your solution works fine for Gaussians that also happen to be rigid or nonrigid members of other rigid bodies, then it works for me.

benmwebb commented 6 years ago

@iecheverria no problem - if the beads are supposed to end up in the bounding box, it should be easy enough for me to fix - just transform the bounding box with the rigid body's reference frame first.