Merge pull request #2790 from RosettaCommons/aleaverfay/fix_rotamer_addition_bug
RotamerSet_::add_rotamer_to_existing bugfix
Fixing a pretty big bug in the way rotamers are added to a RotamerSet_. Back in PR #2111, merged about three weeks ago, I added new code to decrease the number of different residue-types that the RotamerSet thought it was dealing with because before then, any new rotamer was appended to the end, and a rotamer would be considered a new type if its type didn't match the type of the one that proceeded it. There's a good amount of code in the packer, though, that scales quadratically with the number of types per residue. It's silly if you've alternated between lysine and arginine while appending rotamers to your set to declare there being 100 different residue types. (This is all just exposition from that PR)
The bug I introduced in this PR occurred when a rotamer was added to a set that contained only a single type, or when a rotamer was added for the last type in the set (e.g. TYR) which can pretty easily happen! Basically, I wasn't appending rotamers from the last type until I got to the next type -- and this kind of logic will always miss the very last type in the list (there's no next type to trigger rotamer addition) so if you were repacking a residue, you would never get the new rotamers you were trying to add.
Thanks Gideon for the test case that exposed this problem.
Fixing a second, long-standing bug in tracking which rotamer is the input rotamer during rotamer deletion. Previously, if you deleted the input rotamer (in the function that took a vector1< bool > listing which rotamers to delete), the RotamerSet_ would not set the index of the input rotamer to 0 as it should have. This can lead to a segfault with my new code as the index of the input rotamer might be off the end of the rotamers_ vector.
@gideonla