Seemingly stochastic "UNCONVERGED ROTATION MATRIX. RETURNING IDENTITY=300" error when using mdtraj.Trajectory.superpose() about mdtraj HOT 8 CLOSED

I also ran into a similar issue when trying to superpose a trajectory, but changing the atom selections doesn't seem to help. Or at least I haven't found a selection that works. Not all frames of the trajectory have this problem, however.

If I superpose the last frame of the trajectory onto the first frame of the trajectory, there is no issue. However, if I superpose the first frame of the trajectory onto the last frame of trajectory, then the result contains atoms where all XYZ coordinates are identical and the following error is returned:
mdtraj/rmsd/src/theobald_rmsd.cpp UNCONVERGED ROTATION MATRIX. RETURNING IDENTITY=296
Edit: I can't seem to reproduce this today. Frame-wise superpositioning is working fine, but if I try to superpose the entire trajectory then I run into the same error and multiple frames at the start of the trajectory will have all atoms at the same XYZ position.

python=3.9
mdtraj=1.9.7
os=RHEL 8.7

Can start a separate issue if you think this is unrelated.

from mdtraj.

@sukritsingh this issue seemed to be stochastic and we haven't seen it since for other systems so it could have just been system specific. I'm happy to close this issue and reopen in the future if seen again. Thank you for looking into this.

from mdtraj.

Unfortunately every system I've tried it on here can't seem to replicate this issue - do you have any system specific features you can highlight that are causing this problem? Or any files you can share to replicate this issue?

If it passed on the "failed" files in the first attempt, then it may be that there's some numerical weirdness around the rotation matrix computation. Does this convergence issue arise regardless of which atoms you use in superpose?

from mdtraj.

This seems related but I think I'm having some issues just getting to the bottom of the issue. Could you elaborate a bit more or provide an example file/code snippet? I'm having some trouble replicating this issue with any of the files I have.

It sounds like you are able to load in to MDTraj Trajectory objects fine, and I would superpose them like this:

# Load in two structures
struc = md.load("structure1.pdb")
struc2 = md.load("structure2.pdb")

# define selection atoms 
strucAtoms = struc.top.select("backbone")
struc2Atoms =struc2.top.select("backbone")

# superpose A to B and then B to A
struc.superpose(struc2, 0, strucAtoms, struc2Atoms)
struc2.superpose(struc, 0, struc2Atoms, strucAtoms)

Both of the two superpose commands work without returning any errors as long as the right number/set of atoms are chosen.

from mdtraj.

I can provide a test case if you want, but it seems to me that the issue was some very mobile atoms sneaking into the atom selection. It would be nice if the superpose method returned raised an error instead of returning incorrect results, but I think it is relatively minor. Not sure if something similar happened for @glass-w

from mdtraj.

it seems to me that the issue was some very mobile atoms sneaking into the atom selection

Possibly but if that's the case then wouldn't removing those atoms (ie choosing a more rigid set of atoms in the selection) alleviate this issue? It sounds like that wasn't necessarily the case here but I may be misunderstanding.

We could consider editing it to throw an error instead of returning the same XYZ results for sure, but I think ultimately this should be a rare issue anyways only coming up when you're identifying an appropriate atom selection to align on, no?

from mdtraj.

Yes, removing the atoms fixed the problem for me. At first I thought it did not, but I could not reproduce that behavior later. Perhaps that was because the Trajectory object was already incorrect and I forgot to reload it.

And I think it should be rare, but occasionally I won't even get the "mdtraj/rmsd/src/theobald_rmsd.cpp UNCONVERGED ROTATION MATRIX. RETURNING IDENTITY=296" warning. I can just check to see if atoms have been superposed on a single point, though.

My problem may also be slightly different from the original issue.

from mdtraj.

Was any resolution achieved here? In general I tend to avoid using less mobile atoms at the termini for these calculations, and I was never able to replicate this issue with any of my systems.

from mdtraj.