![]() |
Rosetta
2021.16
|
This class takes an EnzConstraintIO object and generates a 3D model of the theozyme in it, where inverse rotamers are generated for every block in the cstfile. It gets complicated when ambiguous interactions are specified and other residues are interacting (possibly in ambiguous fashion) with these ambiguous residues... More...
#include <InvrotTree.hh>

Public Member Functions | |
| TheozymeInvrotTree (EnzConstraintIOCOP enzcst_io) | |
| ~TheozymeInvrotTree () override | |
| void | generate_targets_and_inverse_rotamers () override |
| this function generates the 'target' for the inverse rotamers, i.e. in the case of enzdes, simply the coordinates for the ligand if in the future somebody wants to use this to build inverse rotamers against a protein, this function can be reimplemented. called from the constructor, is this really the best idea? More... | |
| bool | check_pose_tree_compatibility (core::pose::Pose &pose) const override |
| important function 2: after a chain/pose has been generated, check whether it's compatible with the inverse rotamers in the tree this can change the pose again More... | |
Public Member Functions inherited from protocols::toolbox::match_enzdes_util::InvrotTree | |
| InvrotTree () | |
| ~InvrotTree () override | |
| core::scoring::constraints::ConstraintCOP | get_constraint_for_target_state (core::Size target_state) const |
| void | generate_inverse_rotamer_constraints (core::pose::Pose const &pose, AllowedSeqposForGeomCstCOP geomcst_seqpos) |
| the main function, generate the constraints More... | |
| utility::vector1 < InvrotCollectorCOP > | collect_all_inverse_rotamers () const |
| convenience access function to the inverse rotamers in the tree note: the returned invrots can contain duplications, as every unique definition of the tree is returned More... | |
| void | dump_invrots_tree_as_multimodel_pdbs (std::string filename_base) const |
| visualization this can lead to several files being written, depending on the ambiguities in the tree More... | |
| core::Size | num_target_states () const |
Private Attributes | |
| EnzConstraintIOCOP | enzcst_io_ |
Additional Inherited Members | |
Public Types inherited from protocols::toolbox::match_enzdes_util::InvrotTree | |
| typedef core::Size | Size |
Protected Member Functions inherited from protocols::toolbox::match_enzdes_util::InvrotTree | |
| void | clear_target_states () |
| void | add_to_targets (InvrotTargetOP invrot_target) |
This class takes an EnzConstraintIO object and generates a 3D model of the theozyme in it, where inverse rotamers are generated for every block in the cstfile. It gets complicated when ambiguous interactions are specified and other residues are interacting (possibly in ambiguous fashion) with these ambiguous residues...
| protocols::toolbox::match_enzdes_util::TheozymeInvrotTree::TheozymeInvrotTree | ( | EnzConstraintIOCOP | enzcst_io | ) |
|
overridedefault |
|
overridevirtual |
important function 2: after a chain/pose has been generated, check whether it's compatible with the inverse rotamers in the tree this can change the pose again
Implements protocols::toolbox::match_enzdes_util::InvrotTree.
|
overridevirtual |
this function generates the 'target' for the inverse rotamers, i.e. in the case of enzdes, simply the coordinates for the ligand if in the future somebody wants to use this to build inverse rotamers against a protein, this function can be reimplemented. called from the constructor, is this really the best idea?
Implements protocols::toolbox::match_enzdes_util::InvrotTree.
References protocols::toolbox::match_enzdes_util::InvrotTree::add_to_targets(), core::pack::rotamer_set::bb_independent_rotamers(), protocols::toolbox::match_enzdes_util::InvrotTree::clear_target_states(), core::conformation::ResidueFactory::create_residue(), enzcst_io_, protocols::toolbox::match_enzdes_util::InvrotTree::num_target_states(), and protocols::toolbox::match_enzdes_util::tr().
|
private |
Referenced by generate_targets_and_inverse_rotamers().
1.8.7