Merge pull request #3238 from RosettaCommons/JWLabonte/sugars/sampling2
ShearMover: Refactoring BackboneMover code to allow for shearing of non-peptide linkages
This merge refactors and simplifies the archaic code of `BackboneMover` to remove most of the hard-coded assumptions and setup a much simpler framework for moves of NCAAs and non-peptides. I am doing this primarily to introduce shear moving of sugars, which was impossible with the previous framework, but it should be much easier to code up shearing for other systems now.
FWIW, historical shear moving of a standard peptide linkage only works because a trans peptide bond (omega) forces the two bonds on either side [psi(n-1) and phi(n)] to be nearly parallel. To make a shearing motion, minimizing downstream effects, the two twisting bonds must be near-parallel, and the bond twists must occur in opposite directions with equal magnitude. If the bonds are not near parallel, the chain will spiral.
In non-peptide cases, there is no guarantee of any particular bonds being near-parallel to each other, so functions had to be written to search for nearby bonds with similar directional/3D orientations.
In the setup phase of the `BackboneMover`s, a list of moving `TorsionID`s is now stored for every "position", removing any hardcoding of which torsions are moving and allowing for shearing of any system.
This major change to shearing code means that Rosetta no longer will be guaranteed to pick the previous residue as the counter-moving residue for peptides; it may now also choose the next residue for the counter move. However, it also means that shearing should work for NCAAs with only very minor modifications.
Some pedantic notes: in this new implementation, the selected counter move is the nearest to parallel, but no cut-off is used, so it is hypothetically possible that a near-orthogonal counter-move is chosen if there are no better options. However, I think that this case should be exceptionally rare, since most systems are going to be extended, and I require that a counter move be at least a bond away. Even if not so, such a "defective" shear move would effectively be like a small move. It could also be noted that a "less-parallel" bond that is a bond away may be less disruptive than a "more-parallel" bond that is three bonds away. I don't think the difference is worth the extra complexity involved to check for this, again, since a shear move is a small move to begin with. That is, if a move has two shearing counter-move options, the system doesn't test for the least disruptive; it tests for the closest to parallel bond, but both options would at least be shearing and therefore not as disruptive as other options.
A large number of integration test changes are expected, from any tests that use glycans, `SmallMover`, `ShearMover` or any torsion-moving across branches, such as ubiquitin tests. All unit tests pass, and old tests were expanded and new ones written to ensure that shearing is behaving as expected. To the best of my knowledge, things work differently but they still work as they should. If this causes anyone problems, please let me know.