imp
imp copied to clipboard
salilab
reference frame orientations
If the rigid body we're looking at has no symmetries, the axes for its inertial tensor are uniquely defined. I understand a algebra::ReferenceFrame3D as a set of three unitary orthogonal vectors indicating the local reference frame and an additional vector indicating a translation from the global origin. What is made in IMP in order to make sure that the first three vectors always point towards the same direction? i.e. to avoid (x,y,z)->(-x,-y,-z) due to numerical uncertainty issues? I'm asking because I hit on these issues, obviously.
Nothing is done at the moment, mostly because I could't think of anything particularly interesting/reliable. Ideas to make this more reliable are needed, however, I'm not sure that any set of ideas will really make it stable in all cases and so avoiding that assumption may, ultimately, be the only workable solution.
For example, building a rigid body, write out a pdb with the internal coordinates (eg by setting the reference frame to the default one) and then, in the future, loading that pdb back and creating the rigid body with the default reference frame (a nice function for this is missing), might be the best approach.
On Mon, Mar 24, 2014 at 11:58 AM, Yannick [email protected] wrote:
If the rigid body we're looking at has no symmetries, the axes for its inertial tensor are uniquely defined. I understand a algebra::ReferenceFrame3D as a set of three unitary orthogonal vectors indicating the local reference frame and an additional vector indicating a translation from the global origin. What is made in IMP in order to make sure that the first three vectors always point towards the same direction? i.e. to avoid (x,y,z)->(-x,-y,-z) due to numerical uncertainty issues? I'm asking because I hit on these issues, obviously.
Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/773 .
This is pretty easy to fix if the rigid body contains at least three xyzs. Suppose their coordinates are stored in o, x and y then the following builds an orthonormal basis (using numpy)
e1 = (x-o)/sqrt(((x-o)**2).sum())
e2 = (y-o) - dot(y-o,e1)*e1
e2 = e2/sqrt((e2**2).sum())
e3 = cross(e1,e2)
that basis has always the same orientation, so the reference frame can rely on that. However if one of these xyzs is moved independently of the others, it might fail of course.
the solution can be simplified using a single xyz: project its coordinates onto the z axis of the reference frame, and orient the reference frame so that particular projection always has a positive sign.
The caveats with that are:
- you have to handle the case of some of the marker points being in the same direction from the center (and run into the same sorts of numerical issues with that). With pdbs, since this is kind of likely to occur as the first three points will be from the same residue and so spatially close (and generally far from the center of mass).
- as was pointed it, adding or removing or reordering points can change things dramatically
- using a single particle doesn't work as it leaves a rotational degree of freedom You need a pair.
It might be fine in practice.
On Mon, Mar 24, 2014 at 12:44 PM, Yannick [email protected] wrote:
the solution can be simplified using a single xyz: project its coordinates onto the z axis of the reference frame, and orient the reference frame so that particular projection always has a positive sign.
Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/773#issuecomment-38491342 .
- yes let's drop the three-particle solution
- sure. We can always warn that rigid bodies lose their reference frame if they are deformed.
- uh, why is that? there's no rotation allowed if the principal axes are well-defined.
anyway, I'll mark this for the next milestone, because I really need it. I could do it I guess, but then I don't know the rigid body internals at all so I'm sure you'd be faster at it.
by the way, check out
RigidBodyTunnelerand tel me what you think :)
fyi I've written a couple of new classes related to this. Given the problems mentioned in this issue, I had to reimplement a representation for internal coordinates that was stabler than the existing.
core/internal/tunneler_helpers will soon be renamed to coordinate_helpers and contains all sorts of transforms to and from local coordinates (e.g. in the reference frame of one rigid body)
RigidBodyTunneler is a mover that proposes jumps from one conformation to another, in the reference frame of a certain rigid body.
RigidBodyUmbrella allows to put an umbrella-like restraint on the local coordinates of a rigid body wrt another. I use it for umbrella sampling.
Yannick, just curious - what is your purpose in using the tunneler? (I am trying to see if there could be some connection to the kinematics class that Dina and I wrote and allows a representation of a kinematic chain of transformation, using various types of rigid body transformations such as rotational dihedral angle etc., and if the two can benefit from each other or perhaps they deal with completely different things)
On Wed, Apr 23, 2014 at 5:03 AM, Yannick [email protected] wrote:
fyi I've written a couple of new classes related to this. Given the problems mentioned in this issue, I had to reimplement a representation for internal coordinates that was stabler than the existing.
core/internal/tunneler_helpers will soon be renamed to coordinate_helpersand contains all sorts of transforms to and from local coordinates (e.g. in the reference frame of one rigid body)
RigidBodyTunneler is a mover that proposes jumps from one conformation to another, in the reference frame of a certain rigid body.
RigidBodyUmbrella allows to put an umbrella-like restraint on the local coordinates of a rigid body wrt another. I use it for umbrella sampling.
— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/773#issuecomment-41152641 .
Barak
first I should say that all I'm dealing with are translations of the centroid, and rigid body rotations, encoded as quaternions. The tunneler works as follows: You start by giving it a number of entry point coordinates (i.e. center of mass + rotation relative to a reference rb). To propose a move, the tunneler computes the current coordinates C and sees which entry point E is closest to it. Then it picks another entry point F at random, and proposes a move to D such that the vector CD is equal to the vector EF. In that way you tunnel from one entry point to another. Check out the docs if that wasn't very clear.
I should add that if you have a couple of basins separated by a large barrier that should help in jumping from one to another. I would have called it basin hopper, but the name was already taken, and it refers to something else.
I'm not aware of any numerical instabilities involving creation of reference frames with latest IMP, so closing.