Documentation created by Vikram K. Mulligan (email@example.com), Baker laboratory on 26 November 2017.
Note: This page documents the
netcharge score term. For information about the NetCharge Filter, see this page.
Also note: The
netcharge score term is currently unpublished. If you use this in your project, please include Vikram K. Mulligan as an author.
This scoring term is intended for use during design, to penalize deviations from a desired net charge in a pose or region. For example, a user could specify that protein was to have an overall net charge of +1, but that a binding interface was to have a net charge of -2. Because this is a score rather than a design algorithm, it can be used in conjunction with any existing design algorithm that uses the packer (including the FastDesign and PackRotamers movers, or the fixbb application). Moreover, it can be used in conjunction with other score terms that guide design, such as aa_composition.
Calculating a score based on net charge is easy and fast (one need only sum the charges of all amino acids in the protein, take the difference from the desired charge, and look up a suitable penalty for that difference from a lookup table), but the calculation is inherently not pairwise-decomposable. This scoring term is intended to work with Alex Ford's changes to the packer that permit fast-to-calculate but non-pairwise-decomposable scoring terms to be used during packing or design.
To use this term, it must be turned on by reweighting
netcharge to a non-zero value, either in the weights file used to set up the scorefunction, or in the scorefunction definition in RosettaScripts, in PyRosetta, or in C++ code.
This scoring term is controlled by
.charge files, which define the desired charge in a pose or a sub-region of a pose defined by residue selectors. If no
.charge files are provided, then the
netcharge score term always returns a score of zero. The
.charge file(s) to use can be provided to Rosetta in three ways:
.chargefiles as input at the command line with the
-netcharge_setup_file <filename1> <filename2> <filename3> ...flag. The charge specifications will be applied globally, to the whole pose, whenever it is scored with the
.chargefiles when setting up a particular scorefunction in RosettaScripts (or in PyRosetta or C++ code), using the
<Set>tag to modify the scorefunction. The charge specification will be applied globally, to the whole pose, whenever this particular scorefunction is used. For example:
<SCOREFXNS> <ScoreFunction name="r15" weights="ref2015.wts" > <Reweight scoretype="netcharge" weight="1.0" /> <Set netcharge_setup_file="inputs/positive_three.charge" /> </ScoreFunction> </SCOREFXNS>
.chargefiles to a Pose with the AddNetChargeConstraintMover. These remain attached to the pose, like any other constraint, until all constraints are cleared with the ClearConstraintsMover, or until only sequence composition constraints are cleared with the ClearCompositionConstraintsMover. Note that the net charge constraints added with the AddNetChargeConstraintMover can have a ResidueSelector attached to them as well. This allows the user to define sub-regions of the pose (e.g. a single helix, the protein surface, an inter-subunit binding interface) to which a net charge constraint will be applied. The ResidueSelector is evaluated prior to scoring or packing (but not evaluated repeatedly during packing). Here is an example RosettaScript in which a LayerSelector is used to select the surface of the protein, and the AddNetChargeConstraintMover is used to impose the requirement that surface residues only have a net charge of +2:
<ROSETTASCRIPTS> <SCOREFXNS> <ScoreFunction name="r15" weights="ref2015.wts" > <Reweight scoretype="netcharge" weight="1.0" /> </ScoreFunction> </SCOREFXNS> <RESIDUE_SELECTORS> <Layer name="surflayer" select_core="false" select_boundary="false" select_surface="true" core_cutoff="0.5" surface_cutoff="0.25" /> </RESIDUE_SELECTORS> <TASKOPERATIONS> </TASKOPERATIONS> <FILTERS> </FILTERS> <MOVERS> <AddNetChargeConstraintMover name="netcharge_cst" filename="plustwo.charge" selector="surflayer" /> <FastDesign name=fdes1 scorefxn="r15" repeats="3" > <MoveMap name="fdes1_mm"> <Span begin="1" end="30" chi="1" bb="0" /> </MoveMap> </FastDesign> </MOVERS> <APPLY_TO_POSE> </APPLY_TO_POSE> <PROTOCOLS> <Add mover="netcharge_cst" /> <Add mover="fdes1" /> </PROTOCOLS> </ROSETTASCRIPTS>
If the user uses more than one of the methods described above, all of the
.charge files provided will be used in scoring, provided the
netcharge scoreterm is on with a nonzero weight. This can be useful to apply complicated charge requirements, such as, "The net charge of the whole protein must be +1, but the net charge of the first helix must be -3 and the net charge of the binding pocket must be +3".
.charge file defines a single desired net charge, which can either be enforced globally or regionally within a pose. It also defines the penalty function to apply if the actual net charge deviates from the desired net charge. This penalty function is very important: it is what guides the packer towards solutions that have the desired net charge. Ideally, we want the penalty function to gradually ramp down to a minimum at the desired net charge.
.charge file must contain a
DESIRED_CHARGE line, a
PENALTIES_CHARGE_RANGE line, and a
PENALTIES line. Optionally, it may also contain
AFTER_FUNCTION lines. Each of these is defined below:
||The desired net charge for the whole pose or region, expressed as a signed integer. This line is mandatory.||
||The range of possible observed net charges over which penaltes are defined. This line is mandatory.||
||The values that the
||Outside the range of penalties defined in the
||Outside the range of penalties defined in the
Note that the
.charge file does not specify whether the desired net charge is a global or local net charge. That is determined by the manner in which the
.charge file is applied: if it is applied using the AddNetChargeConstraintMover, and a residue selector is provided, it will define the expected charge in a region of a pose; otherwise, it will be applied to the whole pose.
The following example shows a
.charge file requiring that the net charge in a pose or region be exactly 0.
DESIRED_CHARGE 0 #Desired net charge is zero. PENALTIES_CHARGE_RANGE -1 1 #Penalties are listed in the observed net charge range of -1 to +1. PENALTIES 10 0 10 #The penalties are 10 for an observed charge of -1, 0 for an observed charge of 0, and 10 for an observed charge of +1. BEFORE_FUNCTION QUADRATIC #Ramp quadratically for observed net charges of -2 or less. AFTER_FUNCTION QUADRATIC #Ramp quadratically for observed net charges of +2 or greater.
The following example shows a
.charge file requiring that the net charge in a pose or region be in the range of -1 to +3. Within this range, the penalty returned is zero; outside of this range, it rapidly becomes positive.
DESIRED_CHARGE 0 #Desired net charge is zero. PENALTIES_CHARGE_RANGE -2 4 #Penalties are listed in the observed net charge range of -2 to +4. PENALTIES 10 0 0 0 0 0 10 #The penalties are 10 for an observed charge of -2, 0 for an observed charge of -1 to +3, and 10 for an observed charge of +4. BEFORE_FUNCTION QUADRATIC #Ramp quadratically for observed net charges of -3 or less. AFTER_FUNCTION QUADRATIC #Ramp quadratically for observed net charges of +5 or greater.
CONSTANT out-of-bounds behaviour is useful in cases in which we want to specify a maximum but no minimum or a minimum but no maximum. In this case, we specify that we want a net charge of, at most, -3.
DESIRED_CHARGE -3 #Desired net charge is -3. PENALTIES_CHARGE_RANGE -4 -2 #Penalties are listed in the observed net charge range of -4 to -2. PENALTIES 0 0 10 #The penalties are 0 for an observed charge of -4, 0 for an observed charge of -3, and 10 for an observed charge of -2. BEFORE_FUNCTION CONSTANT #Return 0 for observed net charges of -5 or less. AFTER_FUNCTION QUADRATIC #Ramp quadratically for observed net charges of -1 or greater.
.charge file format is sufficietly versatile to allow us to penalize net charges near zero, but allow net charges that are either very positive or very negative. Here's an example:
DESIRED_CHARGE 0 #Desired net charge is zero. PENALTIES_CHARGE_RANGE -2 2 #Penalties are listed in the observed net charge range of -2 to +2. PENALTIES 0 25 50 25 0 #The penalties are 0 for an observed charge of -2 or +2, 25 for an observed charge of -1 or +1, and 50 for an observed charge of 0. BEFORE_FUNCTION CONSTANT #Return 0 for observed net charges of -3 or less. AFTER_FUNCTION CONSTANT #Return 0 for observed net charges of +3 or greater.
A desired net charge for a region in a pose (e.g. the binder in a binder-target complex, a single helix of a larger protein, a binding interface) can be set using net charge constraints. Like geometric constraints, these are attached to a pose, and are read by the
netcharge score term when the pose is scored or packed. Net charge constraints can be added with the AddNetChargeConstraintMover. An example, in which a binding interface is selected with a residue selector and constrained to have a net negative charge, is shown below:
<ROSETTASCRIPTS> <SCOREFXNS> <ScoreFunction name="r15" weights="ref2015.wts" > <Reweight scoretype="netcharge" weight="1.0" /> </ScoreFunction> </SCOREFXNS> <RESIDUE_SELECTORS> # The interface is selected by selecting residues in chain A that are within 15 Angstroms of residue 53 in chain B: <Index name="select_b53" resnums="53B" /> <Chain name="select_chainA" chains="A" /> <Neighborhood name="select_near_b53" selector="select_b53" distance="15.0" /> <And name="select_interface" selectors="select_chainA,select_near_b53" /> <Not name="select_not_interface" selector="select_interface" /> </RESIDUE_SELECTORS> <TASKOPERATIONS> # We set up task operations to prevent design away from the interface: <OperateOnResidueSubset name="only_repack_not_interface" selector="select_not_interface" > <RestrictToRepackingRLT /> </OperateOnResidueSubset> </TASKOPERATIONS> <FILTERS> </FILTERS> <MOVERS> <AddNetChargeConstraintMover name="netcharge_cst" filename="must_be_negative.charge" selector="select_interface" /> <FastDesign name=fdes1 scorefxn="r15" repeats="3" task_operations="only_repack_not_interface" /> </MOVERS> <APPLY_TO_POSE> </APPLY_TO_POSE> <PROTOCOLS> <Add mover="netcharge_cst" /> <Add mover="fdes1" /> </PROTOCOLS> </ROSETTASCRIPTS>
netcharge score term should be fully compatible with symmetry, including mirror symmetry. Note that it counts all residues in the pose or selection, not only those in the asymmetric unit.
netcharge score term should be fully compatible with the aa_composition score term, the hbnet score term, or any other design-centric score term. The power of these terms is enhanced when used together. For example, with a combination of
aa_composition, a user could effectively say, "Design both sides of this interface, and give me designs with a 50/50 mix of polar and hydrophobic amino acids on each side of the interface, a maximum of 4 charged residues on each side of the interface, and a net charge of +2 on one side and -2 on the other." By adding the
hbnet term as well, one could ensure that the designs returned had hydrogen bond networks wherever possible in addition.
finalize_total_energy()function that takes a pose. This calculates the score. Internally, it calls
calculate_energy(), which takes a vector of owning pointers to Residues (which can be called directly during packing).
core/scoring/netcharge_energy/NetChargeEnergySetup.hh. NetChargeEnergySetup objects can also be stored in NetChargeConstraints associated with a Pose. At scoring or packing time, the NetChargeEnergy constructs a vector of owning pointers to its internal NetChargeEnergySetup objects and to all those stored in the pose, and uses all of these for scoring.
.chargefiles are located in