HBNet is a method to explicitly detect and design hydrogen bond networks within Rosetta. It functions as a mover within the RosettaScripts framework and will exhaustively search for all networks within the design space that you define with TaskOperations, and that meet the criteria you specify with the options below
The new Monte Carlo sampling approach (MC HBNet) is now in master and it is highly recommended (likely become the default soon); to use it, simply add
monte_carlo="true" to the existing HBNet or HBNetStapleInterface movers. The new MC search procedure is much faster, enables consistent runtimes and memory usage, and consistently yields a larger number of high-quality networks in a much shorter runtime. To control the number of MC trials, set
total_num_mc_runs="10000"; making this value smaller will result in shorter runtimes, making it bigger will result in longer runtimes (and often more solutions). Other MC HBNet options are listed below. Setup, network evaluation/ranking, and output are still handled the same as in HBNet.
In general, HBNet should work with any existing XML by placing it in the beginning of your design steps. Because HBNet returns multiple poses (each with different networks or combinations of networks), everything downstream of HBNet must use the MultiplePoseMover.
HBNetStapleInterfacemover in your PROTOCOLS block before your main design steps
MultiplePoseMover(MPM) immediately after HBNet; then inside the MPM, paste your normal design XML; this will design your pose as you normally would, but with the networks already there and fixed in place.
_cstscorefxns for design steps post-HBNet; for example
beta_cstrather than beta.
<ROSETTASCRIPTS> <SCOREFXNS> PASTE YOUR SCFXN HERE AND THEN PASS IT TO HBNET </SCOREFXNS> <TASKOPERATIONS> PASTE YOUR TASK_OPERATIONS HERE AND THEN PASS THEM TO HBNET </TASKOPERATIONS> <FILTERS> </FILTERS> <MOVERS> <HBNet name="hbnet_mover" scorefxn=[YOUR_SCORE_FUNCTION] hb_threshold="-0.5" min_network_size="3" max_unsat_Hpol="1" write_network_pdbs="1" monte_carlo="false" task_operations=[YOUR_TASK_OPS_HERE] /> <MultiplePoseMover name="MPM_design" max_input_poses="100"> <ROSETTASCRIPTS> PASTE YOUR ENTIRE CURRENT DESIGN XML HERE # only use _cst scorefxn during design to make sure the constraints automatically turned on by HBNet are respected # residue selector and taskop to ensure network residues aren't designed away # residue selector will automatically detect all HBNet residues <ResiduePDBInfoHasLabel name="hbnet_residues" property="HBNet" /> <OperateOnResidueSubset name="hbnet_task" selector="hbnet_residues"> <RestrictToRepackingRLT/> # can also use PreventRepackingRLT here, but I find that repack only works best, because it allows some wiggle room, and the csts applied automatically by h-bond keep the h-bonds in place </OperateOnResidueSubset> </ROSETTASCRIPTS> </MultiplePoseMover> <PROTOCOLS> <Add mover_name="hbnet_mover"/> <Add mover_name="MPM_design"/> </PROTOCOLS> </ROSETTASCRIPTS>
HBNet is a base classes that can be derived from to override key functions that do the setup, design and processing of the networks differently:
Expects a pose with >= 2 chains and will by default start the network search at all interface residues, attempting to find h-bond networks that span across the interface.
# symmetric <HBNetStapleInterface scorefxn="hard_symm" name="hbnet_interf" hb_threshold="-0.5"design_residues="NSTQHYW" write_network_pdbs="true" min_networks_per_pose="1" max_networks_per_pose="4" use_aa_dependent_weights="true" min_core_res="2" min_network_size="3" max_unsat_Hpol="3" onebody_hb_threshold="-0.3" task_operations="arochi,init_layers,current" /> # asymmetric <HBNetStapleInterface scorefxn="hard" name="hbnet_interf" hb_threshold="-0.5"design_residues="NSTQHYW" write_network_pdbs="true" min_intermolecular_hbonds="3" min_networks_per_pose="1" max_networks_per_pose="4" use_aa_dependent_weights="true" min_core_res="2" min_network_size="3" max_unsat_Hpol="3" task_operations="arochi,init_layers,current" />
min_helices_contacted_by_network="4"would require that 4 different helices each contribute at least 1 rotamer to each h-bond network for it to pass
max_networks_per_pose="4"will try outputting combinations of between 2 to 4 compatible networks at once when returning output poses.
There used to be HBNetLigand and HBNetCore movers, but both of these design cases are better accomplished now by using the regular HBNet mover with the right options (see below):
The default is that it will start searching at all positions in the monomeric Pose, which is often note ideal: if possible specify
start_selector to start at positions you want to potentially be part of the networks, and define your design space carefully with
<HBNet scorefxn="beta" monte_carlo_branch="true" total_num_mc_runs="100000" core_selector="core" name="hbnet" hb_threshold="-0.5" min_core_res="2" minimize="false" min_network_size="5" max_unsat_Hpol="2" start_selector="[YOUR_SELECTOR]" task_operations="[YOUR TASKOPS" />
If your goal is to design a network that satisfies a polar small molecule, use
start_selector to start at the ligand (and any first shell contacts you might want to keep). One challenge that arose in these design cases is that HBNet only searches for networks among packable/designable positions, but often users want to keep the ligand and some first-shell contacts fixed (NATRO or PreventRepacking). To solve this issue, we added the option
use_only_input_rot_for_start_res, which if true, takes the
start_selector positions, fixes their identity, turns on proton Chi sampling, but otherwise fixes their rotamer. This allows for more h-bonding possibilities by sampling multiple Hpol positions. (Option added together with Benjamin Basanta; commutativity logic reworked by Vikram K. Mulligan.)
use_only_input_rot_for_start_res only works if set to true and if the start selector is set to be packable. If using an abnormal starting rotamer, IncludeCurrent is recommended to ensure that this flag will not cause your start vector to be empty.
<HBNet name="hbnet_ligand" scorefxn="standardfxn" hb_threshold="-0.5" start_selector="ligand" design_residues="STNQYW" write_cst_files="False" write_network_pdbs="False" store_subnetworks="False" minimize="False" min_network_size="3" max_unsat_Hpol="0" task_operations="no_design_or_pack,limitAroChi,includeCurrent" use_only_input_rot_for_start_res="True"/>
Why do my output poses all have clashes? HBNet will return networks iteratively by placing them onto your input Pose; because each network doesn't constitute the entire design space (packable/design residues) it is common and expected to see clashes between network residues and untouched input residues if you output directly after HBNet; the assumption is that any residues that are packable/designable during HBNet will also be packable/designable during downstream design, which will be performed after HBNet. If this is not desired, you have 2 options:
write_network_pdbs="true"; useful for debugging and inspection (or to check if your network changed during downstream design).
Why is HBNet so slow? The best way to handle this is to now use MC HBNet by passing
monte_carlo="true", but in all cases, especially original HBNet, the runtime will scale with the size of your design space and how many networks are found (which is kind of a catch-22, because you likely want to find a lot of networks). There are several ways to make HBNet much faster (and often get better results too):
hb_thresholdmore stringent (more negative). With MC-HBNet you can safely set it to -0.5; with original HBNet, use -0.5 unless using ex1ex2, in which case start at -0.75
task_operations; the more you can restrict your design space, and especially high-entropy sidechains (Lys/Arg), the better.
start_selectorto only start searching at a small number of positions of interest.