Hi Ben,
I tried to test sth related to the TransformationSymmetry on rigid bodies and I fail to get it work properly in the below simple example.
In the example I create four copies of a chain, create four-fold symmetry constraints and try to generate the updated configuration using model.update(). In the resulting model.rmf, three chain copies are fine and follow the symmetry but one copy of the chains is weirdly rotated.
What do I do wrong?
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")
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) hs.append(IMP.atom.Hierarchy(chains[0])) rbs.append(IMP.atom.create_rigid_body(chains[0]))
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.rmf') IMP.rmf.add_hierarchies(modelrmf, hs) IMP.rmf.save_frame(modelrmf)
Using IMP 2.13.0.
Best, Jan
On 8/22/20 2:30 PM, Jan Kosinski wrote: > I tried to test sth related to the TransformationSymmetry on rigid > bodies and I fail to get it work properly in the below simple example. > > In the example I create four copies of a chain, create four-fold > symmetry constraints and try to generate the updated configuration using > model.update(). In the resulting model.rmf, three chain copies are fine > and follow the symmetry but one copy of the chains is weirdly rotated.
Your script looks OK to me. I would need to see your input PDB to say for sure, but TransformationSymmetry on a rigid body sets the reference frame of the body, i.e. the coordinate system used for all particles in that body, not the global coordinates of the member particles. I expect if you examine the rigid bodies' reference frames, you'll see they're related by the transformation correctly. The initial reference frame of a rigid body is (usually) the principal axes of the members, not the origin of the global coordinate system, so my guess is that these don't all line up in your case.
Ben
Hi Ben,
OKay, I see, I think it’s like you suggest, but I have to add some crazy code block to update the members, as below in bold:
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")
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) hs.append(IMP.atom.Hierarchy(chains[0])) rbs.append(IMP.atom.create_rigid_body(chains[0]))
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)
#crazy code block: for rb in rbs: rb.update_members() m.update() for rb in rbs: rb.set_reference_frame(rb.get_reference_frame()) #this updates the members immediately too m.update() #end of the crazy code block
modelrmf = RMF.create_rmf_file('model.rmf') IMP.rmf.add_hierarchies(modelrmf, hs) IMP.rmf.save_frame(modelrmf)
If skip any of the updates, the members do not get all updated. Is there an easier way to update the members here?
For the PDB file, I take it from your examples (IMP.core.get_example_path('example_protein.pdb')) so I guess you can just run this script if you want to see the PDB file and the result.
Best, Jan
> On 24. Aug 2020, at 23:57, Ben Webb ben@salilab.org wrote: > > On 8/22/20 2:30 PM, Jan Kosinski wrote: >> I tried to test sth related to the TransformationSymmetry on rigid bodies and I fail to get it work properly in the below simple example. >> In the example I create four copies of a chain, create four-fold symmetry constraints and try to generate the updated configuration using model.update(). In the resulting model.rmf, three chain copies are fine and follow the symmetry but one copy of the chains is weirdly rotated. > > Your script looks OK to me. I would need to see your input PDB to say for sure, but TransformationSymmetry on a rigid body sets the reference frame of the body, i.e. the coordinate system used for all particles in that body, not the global coordinates of the member particles. I expect if you examine the rigid bodies' reference frames, you'll see they're related by the transformation correctly. The initial reference frame of a rigid body is (usually) the principal axes of the members, not the origin of the global coordinate system, so my guess is that these don't all line up in your case. > > Ben > -- > ben@salilab.org 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 > https://salilab.org/mailman/listinfo/imp-users
On 8/25/20 5:47 AM, Jan Kosinski wrote: > OKay, I see, I think it’s like you suggest, but I have to add some crazy > code block to update the members, as below in bold: ... > *#crazy code block:* > *for rb in rbs:* > * rb.update_members()* > *m.update()* > *for rb in rbs:* > * rb.set_reference_frame(rb.get_reference_frame()) #this updates the > members immediately too* > *m.update()* > *#end of the crazy code block*
Hmm, this sounds like something isn't right with the dependencies, so updates aren't happening automatically in the right order (although odd that it works for some chains and not others). I'll open an issue.
Ben
Hi Ben,
Thanks! One more observation - it seems that there is some randomness to it. If I run the below script (with just a single model.update() ) multiple times like this: for i in {1..20}; do python example.py $i; done
I get some configurations that are correct and some they are not. But not always, sometimes all 20 models are the same. Much more randomness when run my laptop comparing to our compute cluster. Really strange. Sth related to random seeds? Filesystems?
import IMP import IMP.core import IMP.atom import IMP.container import IMP.rmf import RMF import sys
out_id = str(sys.argv[1]) sys.argv = sys.argv[:1] IMP.setup_from_argv(sys.argv, "rigid bodies")
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) hs.append(IMP.atom.Hierarchy(chains[0])) rbs.append(IMP.atom.create_rigid_body(chains[0]))
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 26. Aug 2020, at 20:09, Ben Webb ben@salilab.org wrote: > > On 8/25/20 5:47 AM, Jan Kosinski wrote: >> OKay, I see, I think it’s like you suggest, but I have to add some crazy code block to update the members, as below in bold: > ... >> *#crazy code block:* >> *for rb in rbs:* >> * rb.update_members()* >> *m.update()* >> *for rb in rbs:* >> * rb.set_reference_frame(rb.get_reference_frame()) #this updates the members immediately too* >> *m.update()* >> *#end of the crazy code block* > > Hmm, this sounds like something isn't right with the dependencies, so updates aren't happening automatically in the right order (although odd that it works for some chains and not others). I'll open an issue. > > Ben > -- > ben@salilab.org 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 > https://salilab.org/mailman/listinfo/imp-users
Tracked and resolved at https://github.com/salilab/imp/issues/1032
On 8/26/20 11:09 AM, Ben Webb wrote: > On 8/25/20 5:47 AM, Jan Kosinski wrote: >> OKay, I see, I think it’s like you suggest, but I have to add some >> crazy code block to update the members, as below in bold: > ... >> *#crazy code block:* >> *for rb in rbs:* >> * rb.update_members()* >> *m.update()* >> *for rb in rbs:* >> * rb.set_reference_frame(rb.get_reference_frame()) #this updates >> the members immediately too* >> *m.update()* >> *#end of the crazy code block* > > Hmm, this sounds like something isn't right with the dependencies, so > updates aren't happening automatically in the right order (although odd > that it works for some chains and not others). I'll open an issue. > > Ben
Thanks, will test it! Do you think it could be added as an option also to DegreesOfFreedom.create_rigid_body ?
Best, Jan
> On 19. Nov 2020, at 01:20, Ben Webb ben@salilab.org wrote: > > Tracked and resolved at https://github.com/salilab/imp/issues/1032 > > > On 8/26/20 11:09 AM, Ben Webb wrote: >> On 8/25/20 5:47 AM, Jan Kosinski wrote: >>> OKay, I see, I think it’s like you suggest, but I have to add some crazy code block to update the members, as below in bold: >> ... >>> *#crazy code block:* >>> *for rb in rbs:* >>> * rb.update_members()* >>> *m.update()* >>> *for rb in rbs:* >>> * rb.set_reference_frame(rb.get_reference_frame()) #this updates the members immediately too* >>> *m.update()* >>> *#end of the crazy code block* >> Hmm, this sounds like something isn't right with the dependencies, so updates aren't happening automatically in the right order (although odd that it works for some chains and not others). I'll open an issue. >> Ben > > > -- > ben@salilab.org https://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle
What problem are you trying to solve here?
Ben
On 11/19/20 11:34 AM, Jan Kosinski wrote: > Thanks, will test it! Do you think it could be added as an option also to DegreesOfFreedom.create_rigid_body ? > > Best, > Jan > >> On 19. Nov 2020, at 01:20, Ben Webb ben@salilab.org wrote: >> >> Tracked and resolved at https://github.com/salilab/imp/issues/1032 >> >> >> On 8/26/20 11:09 AM, Ben Webb wrote: >>> On 8/25/20 5:47 AM, Jan Kosinski wrote: >>>> OKay, I see, I think it’s like you suggest, but I have to add some crazy code block to update the members, as below in bold: >>> ... >>>> *#crazy code block:* >>>> *for rb in rbs:* >>>> * rb.update_members()* >>>> *m.update()* >>>> *for rb in rbs:* >>>> * rb.set_reference_frame(rb.get_reference_frame()) #this updates the members immediately too* >>>> *m.update()* >>>> *#end of the crazy code block* >>> Hmm, this sounds like something isn't right with the dependencies, so updates aren't happening automatically in the right order (although odd that it works for some chains and not others). I'll open an issue. >>> Ben >> >> >> -- >> ben@salilab.org https://salilab.org/~ben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >
Hi Ben,
So, the solution you proposed is to use IMP.atom.create_compatible_rigid_body() for all but the first rigid body. That is fine and indeed works for the example script. Thanks a lot!
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.
And, actually why the reference frames of the same structure read twice cannot be guaranteed to be the same?
Best, Jan
> On 20. Nov 2020, at 19:32, Ben Webb ben@salilab.org wrote: > > What problem are you trying to solve here? > > Ben > > On 11/19/20 11:34 AM, Jan Kosinski wrote: >> Thanks, will test it! Do you think it could be added as an option also to DegreesOfFreedom.create_rigid_body ? >> Best, >> Jan >>> On 19. Nov 2020, at 01:20, Ben Webb ben@salilab.org wrote: >>> >>> Tracked and resolved at https://github.com/salilab/imp/issues/1032 >>> >>> >>> On 8/26/20 11:09 AM, Ben Webb wrote: >>>> On 8/25/20 5:47 AM, Jan Kosinski wrote: >>>>> OKay, I see, I think it’s like you suggest, but I have to add some crazy code block to update the members, as below in bold: >>>> ... >>>>> *#crazy code block:* >>>>> *for rb in rbs:* >>>>> * rb.update_members()* >>>>> *m.update()* >>>>> *for rb in rbs:* >>>>> * rb.set_reference_frame(rb.get_reference_frame()) #this updates the members immediately too* >>>>> *m.update()* >>>>> *#end of the crazy code block* >>>> Hmm, this sounds like something isn't right with the dependencies, so updates aren't happening automatically in the right order (although odd that it works for some chains and not others). I'll open an issue. >>>> Ben >>> >>> >>> -- >>> ben@salilab.org https://salilab.org/~ben/ >>> "It is a capital mistake to theorize before one has data." >>> - Sir Arthur Conan Doyle > > > -- > ben@salilab.org 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 > https://salilab.org/mailman/listinfo/imp-users
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...
If it doesn't, likely this is a different problem and you should open an issue at 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
Hi guys,
indeed we fixed pmi, because we were aware of this issues:
https://github.com/salilab/pmi/commit/ba21ce0986e5d22c0561b69a92e87c71ef82ad...
>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 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... > > If it doesn't, likely this is a different problem and you should open an > issue at 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 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 > https://salilab.org/mailman/listinfo/imp-users >
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
> But Riccardo, we still have problems sometimes with rigid bodies created using dof not following symmetry in some frames
You mean that randomly rigid bodies defined on copies are randomly rotated for a single frame, am I right? I think we saw that issue already.
On Sat, Dec 5, 2020 at 9:22 PM Jan Kosinski jan.kosinski@embl.de wrote:
> 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... > > 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 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... >> >> If it doesn't, likely this is a different problem and you should open an >> issue at 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 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 >> https://salilab.org/mailman/listinfo/imp-users >> > _______________________________________________ > IMP-users mailing list > IMP-users@salilab.org > https://salilab.org/mailman/listinfo/imp-users > > > _______________________________________________ > IMP-users mailing list > IMP-users@salilab.org > https://salilab.org/mailman/listinfo/imp-users >
> You mean that randomly rigid bodies defined on copies are randomly rotated for a single frame, am I right? > I think we saw that issue already.
Yes!
> On 5. Dec 2020, at 22:01, Riccardo Pellarin pellarin.riccardo@gmail.com wrote: > > > But Riccardo, we still have problems sometimes with rigid bodies created using dof not following symmetry in some frames > > You mean that randomly rigid bodies defined on copies are randomly rotated for a single frame, am I right? > I think we saw that issue already. > > > On Sat, Dec 5, 2020 at 9:22 PM Jan Kosinski <jan.kosinski@embl.de mailto:jan.kosinski@embl.de> wrote: > 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 http://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 mailto: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 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 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
On 12/5/20 12:21 PM, Jan Kosinski wrote: > 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?.
Sure, but it's a one-time cost - I doubt you'd notice the difference.
> I could imagine things could be slightly different but here the rb > rotations are not different only slightly
Looks like a simple inversion to me, a very slight difference giving a very different result. e.g. -1e-16 and +1e-16 are only very slightly different but are of opposite sign.
> Maybe the create_rigid_body function > could use the PMI fix internally?
It's a workaround. The fix is to use create_compatible_rigid_body. You can certainly use the PMI workaround but then your reference frame won't align with the principal axes of the body, maybe not an issue in your application.
Ben
-
Ben Webb -
Jan Kosinski -
Riccardo Pellarin