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 >