[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-users] Problem with IMP.core.TransformationSymmetry



Hi guys,

indeed we fixed pmi, because we were aware of this issues:

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 <">> 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-L163

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
--
" target="_blank">                      https://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
        - Sir Arthur Conan Doyle
_______________________________________________
IMP-users mailing list
" target="_blank">
https://salilab.org/mailman/listinfo/imp-users