Hi Riccardo,
Ah, ok, I missed that IMP.atom.create_rigid_body actually has a fix for this since 2007. That explains why in our modellings, when we use dof, the problem has not been so big, it’s quire relieving. But Riccardo, we still have problems sometimes with rigid bodies created using dof not following symmetry in some frames, that is why I am investigating. But the problem apparently must be somewhere else, as your PMI fix works (tested with an example below). I will build on the below example to try to reproduce our problem and get back to you.
And, I would keep your PMI fix rather than create_compatible_rigid_body. The create_compatible_rigid_body runs get_transformation_aligning_first_to_second so it seems to be more computationally costly, am I correct Ben?.
Ben, re your comment: >> And, actually why the reference frames of the same structure read >> twice cannot be guaranteed to be the same? > > Something will be ever so slightly different somewhere due to the semi-magical nature of modern CPUs reordering the floating-point operations, speculative prediction, or caching of intermediate results, I expect.
I could imagine things could be slightly different but here the rb rotations are not different only slightly but rather looking like the reference frames were arbitrary. Maybe the create_rigid_body function could use the PMI fix internally?
Best, Jan
The example using PMI fix: import IMP import IMP.core import IMP.atom import IMP.container import IMP.rmf import RMF import sys
IMP.setup_from_argv(sys.argv, "rigid bodies")
for out_id in range(20): m = IMP.Model() rbs = [] hs = [] for i in range(4): mp1 = IMP.atom.read_pdb(IMP.core.get_example_path('example_protein.pdb'), m) chains = IMP.atom.get_by_type(mp1, IMP.atom.CHAIN_TYPE) c = IMP.atom.Hierarchy(chains[0])
com=IMP.atom.CenterOfMass.setup_particle(IMP.Particle(m),IMP.atom.get_leaves(c)) comcoor=IMP.core.XYZ(com).get_coordinates() tr=IMP.algebra.Transformation3D(IMP.algebra.get_identity_rotation_3d(),comcoor) rf = IMP.algebra.ReferenceFrame3D(tr) rbp=IMP.Particle(m) rb=IMP.core.RigidBody.setup_particle(rbp,rf) for h in IMP.atom.get_leaves(c): rb.add_member(h.get_particle())
rbs.append(rb) hs.append(c)
for i, rb in enumerate(rbs[1:]): # the other 3 particles are all symmetric copies of the first IMP.core.Reference.setup_particle(rb, rbs[0]) # the symmetry operation is rotation around the z axis tr = IMP.algebra.Transformation3D( IMP.algebra.get_rotation_about_axis(IMP.algebra.get_basis_vector_3d(2), 2 * 3.14 / len(rbs) * (i + 1)), IMP.algebra.Vector3D(0, 0, 0)) sm = IMP.core.TransformationSymmetry(tr) c = IMP.core.SingletonConstraint(sm, None, m, rb) m.add_score_state(c)
m.update() modelrmf = RMF.create_rmf_file('model{0}.rmf'.format(out_id)) IMP.rmf.add_hierarchies(modelrmf, hs) IMP.rmf.save_frame(modelrmf)
> On 5. Dec 2020, at 08:44, Riccardo Pellarin pellarin.riccardo@gmail.com wrote: > > Hi guys, > > indeed we fixed pmi, because we were aware of this issues: > > https://github.com/salilab/pmi/commit/ba21ce0986e5d22c0561b69a92e87c71ef82ad... https://github.com/salilab/pmi/commit/ba21ce0986e5d22c0561b69a92e87c71ef82ad48#diff-d07fb330cc6ad544e32350551276f823e88ca0e32039cde0be2676e75596e15a > > From what I recall, it works fine. > but that fix can be substituted with create_compatible_rigid_body, > which it is doing the same thing, at least it looks like to me. > > > On Sat, Dec 5, 2020 at 3:13 AM Ben Webb <ben@salilab.org mailto:ben@salilab.org> wrote: > Apologies for the delay - I was on "vacation" (or the best 2020 > approximation of one) last week. > > On 11/24/20 11:37 AM, Jan Kosinski wrote: > > But if one uses the nice DegreesOfFreedom class to create rigid > > bodies via DegreesOfFreedom.create_rigid_body function, it won’t be > > possible to use this fix - the DegreesOfFreedom.create_rigid_body > > function uses IMP.atom.create_rigid_body and does not allow to > > optionally use IMP.atom.create_compatible_rigid_body. > > I just looked at the code, and it looks like the PMI folks were already > aware of this issue, so it *should* work fine: > https://github.com/salilab/pmi/blob/develop/pyext/src/dof/__init__.py#L152-L... https://github.com/salilab/pmi/blob/develop/pyext/src/dof/__init__.py#L152-L163 > > If it doesn't, likely this is a different problem and you should open an > issue at https://github.com/salilab/pmi/issues https://github.com/salilab/pmi/issues > > > And, actually why the reference frames of the same structure read > > twice cannot be guaranteed to be the same? > > Something will be ever so slightly different somewhere due to the > semi-magical nature of modern CPUs reordering the floating-point > operations, speculative prediction, or caching of intermediate results, > I expect. > > Ben > -- > ben@salilab.org mailto:ben@salilab.org https://salilab.org/~ben/ https://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-users mailing list > IMP-users@salilab.org mailto:IMP-users@salilab.org > https://salilab.org/mailman/listinfo/imp-users https://salilab.org/mailman/listinfo/imp-users > _______________________________________________ > IMP-users mailing list > IMP-users@salilab.org > https://salilab.org/mailman/listinfo/imp-users