Merge pull request #2807 from RosettaCommons/roccomoretti/option_tracer_issue
Fix issue with Tracers and options which aren't found.
With the recent tracer re-org, an unknown option results in an error from the Tracer system, as you attempt to use a tracer that hasn't been initialized from options yet. This PR fixes the double-error that occurrs, by merely printing a warning for uninitialized Tracers, rather than dying.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2802 from RosettaCommons/atom-moyer/Kinematics-Stub_from_Residue
Utility functions for returning stub from residue orient atoms and RT from pair of residues
notify author
notify list [rosetta-logs@googlegroups.com]
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
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2794 from RosettaCommons/aleaverfay/template_parameter_indentation_beautifier_change
Beautifying after fixing two issues with the beautifier.
1. The beautifier expected template preambles to include "<" and end with ">";
it's legal, however, to say things like:
template NamedAtomID::NamedAtomID(std::string const &, Size);
where no "<" is ever found. The beautifier now handles this appropriately.
2. The beautifier never properly handled multi-line-template-parameter-list
indentation and so all the lines in the template parameters were flush to the
left, even if the original line was indented. Now all lines after the first
are indented one more level.
I have just now updated the tools/ repo, so I'm closing out this PR.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2781 from RosettaCommons/jadolfbr/dih_cst_generator
Main
===
Add a `DihedralConstraintGenerator` class using @tlinsky 's wonderful `ConstraintGenerator` framework. One instance works on a single dihedral angle type (aka Phi OR Psi). Use multiple generator to add constraints for multiple angles. Mainly works with BB dihedrals, by setting phi,psi,omega (`dihedral` option). Works with glycan backbones as well up to omega2.
Additionally, you can set arbitrary dihedrals by defining the 4 atom names and 4 residues you want. (`dihedral_atoms` and `dihedral_residues` options).
The StandardDeviation for the `CircularHarmonic` Func is set to a default of 16 degrees, which was found by taking the mean SD Within a particular CDR cluster and averaging all of those means together. The 16 degrees represents a good default that allows some movement, as well as useful lever-arm effects, but typically not huge changes to the overall structure of the loops.
Other
====
- Updates to code_templates to remove the THREAD_LOCAL keywords.
- Update rosetta_scripts_jd3 to allow printing of BOTH a RosettaScript template and a JobDefinition template if used without `-job_definition` option
Tests
====
Includes a comprehensive Unit test for the `DihedralConstraintGenerator` testing the setting of particular dihedrals, custom dihedrals, and parsing custom dihedral angles from a RosettaScript.
notify author
notify list [rosetta-logs@googlegroups.com]