Hi guys,

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


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:

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@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