 |
Rosetta Core
2014.16.56682
|
|
Rosetta Core
2014.16.56682
|
A class for defining atom parameters, known as atom_types. More...
Namespaces | |
| chemical | |
| coarse | |
| conformation | |
| environment | |
| fragment | |
| graph | |
| grid | |
| id | |
| import_pose | |
| init | |
| io | |
| kinematics | |
| membrane | |
| optimization | |
| pack | |
| pose | |
| scoring | |
| sequence | |
| util | |
Classes | |
| class | SVNVersion |
Functions | |
| void | set_svn_version_and_url (std::string const &version, std::string const &url) |
| Initialize this data from a lower-level library at startup to avoid relinking every time you update your svn / git version. This function should be called at most once. More... | |
| std::string | minirosetta_svn_version () |
| Read access to the svn / git version. More... | |
| std::string | minirosetta_svn_url () |
| Read access to the svn / git url. More... | |
Variables | |
| static const Size | SZ_MAX = std::numeric_limits<Size>::max() |
A class for defining atom parameters, known as atom_types.
Package Headers.
utility headers
Utility headers.
A class for generating statistics from orbitals.
you cannot #include yourself #include <core/scoring/mm/MMBondLengthScore.hh>
LAZY using.
REPLACE THIS WITH .fwd.hh.
A class for generating the table for fa_atr/rep and fa_sol.
#define APL_TEMP_DEBUG
A class for scoring fa_atr, fa_rep, fa_sol.
Electron density resource options forward header.
Unit Headers.
Phenix Interface.
cant get to compile w/ func::Func.fwd.hh
Declaration of the base class for TaskOperation factory registration and creation.
Base class for TaskOperation factory-registration and creation classes.
Declaration of the base class for ResLvlTaskOperation factory registration and creation.
Base class for ResLvlTaskOperation factory-registration and creation classes.
Declaration of the base class for ResFilter factory registration and creation.
Base class for ResFilter factory-registration and creation classes.
ObjexxFCL.
C++ headers.
Debugging headers.
#include <core/pack/dunbrack/SingleResidueDunbrackLibrary.tmpl.hh>
Numeric headers.
Unit headers.
Membrane Protein Factory.
Utility Headers.
Project Headers.
Project headers.
some utils for fragments
some utilities for fragments
Class: Membrane Spanning Topology.
Membrane Lipid Accessibility Data.
right now there isnt a canonical mapping from nodes back to atom objects.
The conformation class of the atom object.
RNA specific properties.
A class that contains orbital parameters.
A class for reading in the orbital type properties.
A class for defining chemical atoms, with properties specific to a ResidueType, not conformation info specific to a Residue. Conformation info goes in conformaton::Orbital. OrbitalTypes are not ResidueType specific.
Chemical manager class.
A class for holding bond information.
A class for reading in the atom type properties.
A class for defining chemical atoms, with properties specific to the atom. This class should not have information associated with the conformation or residuetype. Everything should be concerning the atom. Conformation goes in core::conformation while data for ResidueTYpe is cached there.
Atom
This class contains the "chemical" information for atoms. This does not contain the actual xyz coordinates of the class (xyz found in core/conformation/Atom.hh. The atom_type properties are assigned by the class AtomSet which is initiated from the ChemicalManager. Atom type properties are currently are read in from the file located chemical/atom_type_sets/fa_standard/atom_properties.txt. These properties contain the the properties of LJ_RADIUS, LJ_WDEPTH, LK_DGRFREE, LK_LAMBDA, LK_VOLUME. These properties are used in the scoring function fa_atr, fa_rep, fa_sol, which is located in the Etable (core/scoring/etable/Etable.hh) Additional parameters are acceptor/donor, hybridzation, and orbital paramaters.
Atom
AtomTypeSet
Bond
Bond
ChemicalManager
core::chemical::AtomTypeSetCAP atom_types = core::chemical::ChemicalManager::get_instance()->atom_type_set("fa_standard");
You can substitute AtomTypeSet, with whatever is seen below (residue_type_set, mm_atom_type_set, orbital_type_set). In the below functions, the "tag_in" refers to fullatom, centroid, which basically tells what type of set to load in. The chemical manager will call functions within the AtomTypeSet, MMAtomTypeSet, ResidueTypeSet, etc etc. The classes type set reads in files from the database to create atom types, residue types, and mmatom types. The information from those files are stored in the type class.
Orbital
Orbital
AtomTypeSet
But wait, you say, why do you store the names of the atoms instead of the index of the atoms!? Well, the problem occurs when residuetype reorders the indices of the atoms. When this occurrs, the indices for the icoor are not reordered here. Another problem ocurs because orbital indices are not reordered in this process because orbital indices are seperate from the atom indices. Regardless, when you build the xyz coords, this step is transparent because the function orbital_xyz() in residue.hh takes care of this conversion of indice to string.
This class contains the "chemical" information for orbitals. This does not contain the actual xyz coordinates of the class which is managed by the conformation/Residue.hh. The orbital_type properties are assigned by the class OrbitalTypeSet which is initiated from the ChemicalManager. Orbital type properties are currently are read in from the file located chemical/orbital_type_sets/fa_standard/orbital_properties.txt. These properties contain the the parameters of distance, but can be modified. Currently this is a very small class that will be added on as more and more properties are identified and added. Note that information about the atomtype is stored along with the orbital type. This may or may not be useful later. Just adding the functionality for shits and giggles.
Orbital type name: the orbital type name contains the hybridization, orbital name, and element associated with the orbital
Hybridization: the hybridiztion of the atom that the orbital is bonded to (sp, sp2, sp3)
Orbital Name: the name of the orbital. This usually is p, d, pi, sigma. The orbital name is different than the orbital type name
Atom Type Name: the type of atom associated with an orbital
Distance: distance the orbital comes off of the atom. Currently, for residues, the distance is the Bohr radius of Hydrogen+element
Donor: does the orbital donate electrons? currently not implemented
Acceptor: is the orbital accept electrons? currently not implemented
This class contains the "chemical" information for orbitals. This does not contain the actual xyz coordinates of the class which is managed by the conformation/Residue.hh. The orbital_type properties are assigned by the class OrbitalTypeSet which is initiated from the ChemicalManager. Orbital type properties are currently are read in from the file located chemical/orbital_type_sets/fa_standard/orbital_properties.txt. These properties contain the the parameters of distance, but can be modified. Currently this is a very small class that will be added on as more and more properties are identified and added. Note that information about the atomtype is stored along with the orbital type. This may or may not be useful later. Just adding the functionality for shits and giggles.
Orbital type name: the orbital type name contains the hybridization, orbital name, and element associated with the orbital
Hybridization: the hybridiztion of the atom that the orbital is bonded to (sp, sp2, sp3)
Orbital Name: the name of the orbital. This usually is p, d, pi, sigma. The orbital name is different than the orbital type name
Atom Type Name: the type of atom associated with an orbital
Distance: distance the orbital comes off of the atom. Currently, for residues, the distance is the Bohr radius of Hydrogen+element
AtomTypeSet
The ResidueSelector is an object the picks out a subset of ResidueTypes, via a bool operator[](ResidueType const &) method. It is implemented as a logical AND of individual constraints, each of which typically has an OR structure. The system allows NOT at the beginning.
AA aa1 aa2 aa3 VARIANT_TYPE type1 type2 type3 PROPERTY property1 property2
So, e.g., the lines
PROPERTY PROTEIN AA PRO GLY NAME3 HPR NOT VARIANT_TYPE PHOSPHO TERMINUS
would define a selector that matched residues with property PROTEIN, with aa types pro or gly, with a three-letter code of HPR and not of variant type PHOSPHO or TERMINUS
The individual constraints that make up the ResidueSelector object are subclasses of ResidueSelectorSingle; ResidueSelector has a vector1 of ResidueSelectorSingleOP's
RNA_residueType
Atom.hh
Stores lipid accessibility data derived from OCTOPUS spanning file and psiblast search using run_lips.pl script
The goal of the membrane info object is to coordinate information related to the conformaiton of a memrbane protein - as it relates to both kinematics and scoring of a pose. The object lives inside of Conformaiton, but maintains an access pointer to the conformation in order to access its data members and check for updates. This class does not inherit from an observer, but implements the observer pattern
Stores information describing the membrane spanning topology of a pose. This definition is a dependency for embedding definitions and requires a spanningfile from OCTOPUS for initialization
Utility headers
Utility headers C++ headers
Initializes a pose as a membrane protein in Rosetta
Initializes a pose as a membrane protein
Package headers Project headers Utility headers
Package headers Project headers Utility headers Numeric headers
Package headers
Package headers ObjexxFCL headers C++ headers
Package headers ObjexxFCL headers
C++ headers
This layer of abstraction between the InteractionGraphBase and the various fixed-backbone interaction graphs is primarily to allow outside users to READ from an interaction graph – to grab data that the interaction graph stores. This is not so much for the writing of information – in particular, edge energies – to an interaction graph.
Be very careful with #includes in this file. As almost every file in Rosetta #includes Pose.hh, any header file #included here will produce a huge recompile when modified. I pledge a personally delivered, hand-crafted ass-whooping for any fool that #includes an unnecessary .hh file in Pose.hh. Allowed .hh files are few: Residue, ResidueType, Conformation, Energies AtomID and NamedAtomID. Everything else should be forward included, or not included at all. The above pledge applies to any header file unnecessarily #included in the .hh files #included here. If Pose were to hold a ConformationOP and an EnergiesOP, and not inline their access, then Residue.hh, ResidueType.hh, Conformation.hh and Energies.hh could be replaced with .fwd.hh's instead.
Hacky (hence the name) implementation of distance dependant dielectric electrostatics, with near and far distance cutoffs.
Hacky (hence the name) implementation of 10r dielectric model, cutoff at 5.5A
Package Headers
core/scoring/methods/electron_density/ElectronDensityOptions.fwd.hh
This is a reimplementation of Jim Havranek's original rosetta++ Gen Born code. source files: rosetta++/gb_elec*
To add an additional option for hydrogen bonds do the following:
In HBondOptions.hh: 1) add it to the default constructor 2) add it to the copy constructor 3) add a getter and a setter 4) add it to operator== 5) add it to the private data 6) add it to HBondOptions::show
To add an additional option for hydrogen bonds do the following: 1) add it to the default constructor 2) add it to the copy constructor 3) add it to the operator= 4) add it to the parse_my_tag 5) add a getter and a setter 6) add it to operator== 7) add it to the private data 8) add it to HBondOptions::show
NOTE– this file includes both string and map, use .fwd.hh if you can!Utility headers
The Two Body Energy Method specifies an interface for all two body methods: both long and short range, both context dependent and independent. Any two body method must implement this interface as well as the EnergyMethod interface.
In this inheritance heirarchy, a common interface is defined for both context dependent and context independent two body energies. Context dependent two body energies require a Pose as context to evaluate the energy and so the interface includes a Pose for all energy evaluation calls.
However, context independent methods do not require a pose, and could conceivably be evaluated in the absence of one. Is the design compromised by demanding a common interface between context independent and context dependent two-body methods? Yes and no. The alternatives are 1) to demand separate, but nearly identical interfaces for ci2b and cd2b classes in which case, the design is compromised by the presence of duplicated code, 2) to use multiple inherritance so that the CI2B class could derive from a two-body interface (shared with the CD2B class) as well as a contex-independent interface (not shared with the CD2B class). The problem is that most of the "shared" interface involves evaluating energies, and for the CD classes, this requires a Pose. The truely shared interface between CI and CD classes would be empty and problem 1 has resurfaced. Moreover, multiple inherritance is difficult to work with and should be avoided.
What is the drawback of requiring a pose for a CI2B method evaluation? It makes it less clear to the energy-method user (not the energy-method writer) that the Pose does not play a role in the evaluation of the ci2b energy. It also makes it possible for the energy-method writer to define a context dependent two body method while declaring it to be context independent: such an act would produce bizzare (wrong) behavior as the innards of the ScoreFunction and the Energies class tried to re-use cached scores that were no longer correct. So the warning must be made:
DANGER! DANGER! DANGER! If the EnergyMethod writer declares a method to be context independent, it had better be!
OrbitalStatistics
For protein interactions, there are 7 classes (orbital types) of orbitals that statistics are generated. These 7 types are mapped using a map to enum data structure. For each sidechain interaction, only the shortest distance between any given orbital type to a hydrogen is calculated. That means, that for each sidechain interaction only 1 distance, 1 angle, and 1 class is recorded.
Bin sizes were calculated by .1A for distance and cos of 1 for angles. See below:
angle -1 -.9 -.8 -.7..........
d .1 | 0 0 0 0 i .2 | 500 0 0 0 s .3 | 25 0 0 0 t .4 | 0 30 5 0
This is not the original code that was used to generate the statistics. The original code was much more convoluted than this because I had no idea how to program. I wrote this piece for clarity. I have tested it and it produces the same results.
Package headers C++ Headers
Package headers Utility headers Numeric headers
| typedef float core::PackerEnergy |
| typedef unsigned short core::ShortSize |
| std::string core::minirosetta_svn_url | ( | ) |
Read access to the svn / git url.
References core::SVNVersion::get_instance(), and core::SVNVersion::url().
Referenced by core::init::init_source_revision().
| std::string core::minirosetta_svn_version | ( | ) |
Read access to the svn / git version.
References core::SVNVersion::get_instance(), and core::SVNVersion::version().
Referenced by core::init::init_source_revision().
| void core::set_svn_version_and_url | ( | std::string const & | version, |
| std::string const & | url | ||
| ) |
Initialize this data from a lower-level library at startup to avoid relinking every time you update your svn / git version. This function should be called at most once.
References core::SVNVersion::get_instance(), and core::SVNVersion::set_svn_version_and_url().
1.8.7