Merge pull request #1998 from RosettaCommons/vmullig/helix_end_sequence_constraints_mover
Add a mover that will set up sequence constraints to require charges at helix termini
**The Problem**
It has been observed that designs with charged residues at the ends of helices that complement the helix macrodipole are often more successful than designs without this feature. Specifically, we want an easy way of imposing the following knowledge-based rule:
- Every helix should have at least one positively-charged residue among its C-terminal 3 residues.
- Every helix should have at least one negatively-charged residue among its N-terminal 3 residues.
Task operations cannot solve this problem: there is no way to set the identity of _at least one_ residue among a group of more than one residue to a desired identity with task operations. One can only force _all_ members of a group to have the desired identity, or risk that, after design, _no_ members of the group might have the desired identity.
**The Solution**
This pull request aims to create a mover that will set up **sequence constraints** imposing the rules above. Analogous to geometric constraints, sequence constraints work with the **aa\_composition** score term to impose a nonlinear penalty for devaition from a desired amino acid composition, and can be applied to sub-regions of a pose (like the N-terminal or C-terminal three residues in a particular helix).
Specifically, the new mover will do the following:
1. Apply DSSP to the pose to detect the secondary structure.
2. For every helix, add two new composition constraints:
2a. A composition constraint requiring at least one negatively-charged residue among the three N-terminal residues of the helix.
2b. A composition constraint requiring at least one positively-charged residue among the three N-terminal residues of the helix.
After applying the mover, the user should be able to design using any design tool that calls the packer (_e.g._ PackRotamersMover, FastDesign, _etc._). So long as the **aa\_composition** score term is turned on in the score function, the rule should be imposed. Note that this turns the packer's optimization problem ("give me the lowest-energy combination of rotamers that you can find") into a constrained optimization problem ("give me the lowest-energy combination of rotamers that you can find, subject to the rules that every helix has at least one negatively-charged residue at its N-terminus and at least one positively-charged residue at its C-terminus").
**Tasks**
- [x] Add the mover using Jared's code template scripts.
- [x] Add options for the N-terminal N residues (with N defaulting to 3) and C-terminal M residues (with M defaulting to 3).
- [x] Add options for disabling the N-terminal or C-terminal constraints
- [x] Add an optional residue selector for restricting the imposition of the rules above to a subset of the overall pose, if the user so wishes.
- [x] XSD information.
- [x] Have the mover call DSSP to identify helices.
- [x] Have it create two residue selectors for each helix, selecting the N-terminal N residues and the C-terminal M residues.
- [x] Have it set up composition constraints requiring at least one negatively-charged residue at the N-terminus and at least one positively-charged residue at the C-terminus of each helix.
- [x] Additional features requested by @grocklin (see comment below).
- [x] Penalize helix-disfavouring residue types.
- [x] User configurable charge counts at helix termini.
- [x] Penalize too many or too few alanines, weakly.
- [x] Penalize too few hydrophobic residues, weakly.
- [x] Unit tests.
- [x] Integration tests.
- [x] Basic setup with default settings only.
- [x] Advanced setup with RosettaScripts-accessible options.
- [x] Beauty.
- [x] Documentation.
- [x] Remove TEMPORARY_NOTE.txt.
**Note**
Frank and Hahnbeom are working on a physics-based solution to this problem that will actually consider the helix macrodipole. The mover that this pull request aims to implement, on the other hand, is a quick and dirty way of imposing prior knowledge, until such time as the physics-based solution is up and running; it is _not_ intended as a permanent solution. Note also that this mover is _only_ for the design step, while Frank and Hahnbeom's solution will ultimately be useful for both design and structure prediction-based validation.
@grocklin @dabaker @hahnbeom @fdimaio