Rosetta  2020.37
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Pages
Namespaces | Typedefs
core Namespace Reference

A class for reading in the atom type properties. More...

Namespaces

 chemical
 
 conformation
 
 energy_methods
 
 environment
 
 enzymes
 
 fragment
 
 grid
 
 id
 
 import_pose
 
 init
 
 io
 
 kinematics
 
 membrane
 
 optimization
 
 pack
 
 pack_basic
 
 pose
 
 scoring
 
 select
 
 sequence
 
 simple_metrics
 
 util
 

Typedefs

typedef platform::Size Size
 
typedef platform::SSize SSize
 
typedef platform::uint uint
 
typedef platform::Real Real
 
typedef unsigned short ShortSize
 
typedef Real Length
 
typedef Real LengthSquared
 
typedef Real Distance
 
typedef Real DistanceSquared
 
typedef Real Volume
 
typedef Real Angle
 
typedef Real Trig
 
typedef Real Mass
 
typedef Real Charge
 
typedef Real Energy
 
typedef Real EnergyDerivative
 
typedef Real Probability
 
typedef float PackerEnergy
 
typedef numeric::xyzVector
< Length
PointPosition
 
typedef numeric::xyzVector
< Length
Vector
 
typedef numeric::xyzVector
< EnergyDerivative
EnergyGradient
 

Detailed Description

A class for reading in the atom type properties.

Package Headers.

utility headers

A class for generating statistics from orbitals.

you cannot #include yourself #include <core/scoring/mm/MMBondLengthScore.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.

Utility headers.

Phenix Interface.

Project headers.

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.

Declaration of the base class for PackerPalette factory registration and creation.

ObjexxFCL.

C++ headers.

Debugging headers.

Numeric headers.

Unit headers.

Project Headers.

Utility Headers.

some utils for fragments

some utilities for fragments

Unit Headers.

Forward header file for class ExactOccludedHbondSolEnergy.

right now there isnt a canonical mapping from nodes back to atom objects.

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.

A class for defining atom parameters, known as atom_types.

MergeBehaviorManager.

Chemical manager class.

A class for holding bond information.

This class reads in the atom_properties.txt file which contains the "chemical" information for atoms. This does not contain the actual properties, but sets the properties through the AtomType class. This class is called by the ChemicalManager

Author
Phil Bradley Steven Combs - comments
Rocco Moretti (rmore.nosp@m.ttia.nosp@m.se@gm.nosp@m.ail..nosp@m.com) Steven Combs
Gordon Lemmon, Rocco Moretti (rmore.nosp@m.ttia.nosp@m.se@gm.nosp@m.ail..nosp@m.com)

The Chemical Manager is a singleton class, which means that it can only been initialized once (exist once in memory). Once initialized, you can call it by simply access it via:

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.

Author
Andrew Leaver-Fay (leave.nosp@m.rfa@.nosp@m.email.nosp@m..unc.nosp@m..edu) Steven Combs - comments
Steven Combs

This class contains the "chemical" information for atoms. This does not contain the actual xyz coordinates of the class (xyz found in core/conformation/Orbital.hh. The atom_type properties are assigned by the class OrbitalSet which is initiated from the ChemicalManager. Orbital 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, hybridization, and orbital parameters.

Author
Phil Bradley Steven Combs - comments
Gordon Lemmon

This class contains the ORBITALS INTERNAL_ICOOR data that is read in from residue_io.cc. Actually, the data is set when residue_io.cc calls the command from residuetype.cc set_orbital_icoor. The data is set and chills out in memory until needed. The actual xyz coordinates are not stored at this point. xyz coordinates are constructed when conformation/Residue.hh asks for the build function in this class. At that point, the coordinates are built and returned.

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.

Note
NOTE!!!!!!!!!!! The internal coordinates cannot contain an orbital as the stub1, stub2, or stub3 atom. This is because the xyz coordinates are not updated when the conformation changes. The stub1, stub2, stub2 atoms must be actual atoms and not orbitals!!!!! (design feature or flaw? you decide)
Author
Steven Combs

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 the heck of it.

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

Author
Steven Combs

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

Author
Steven Combs

This class reads in the orbital_properties.txt file which contains the "chemical" information for orbitals. This does not contain the actual properties, but sets the properties through the OrbitalType class. This class is called by the ChemicalManager. Modeled off of atomtypeset.

Author
Steven Combs
Parin Sripakdeevong (sripa.nosp@m.kpa@.nosp@m.stanf.nosp@m.ord..nosp@m.edu)
Phil Bradley, Ingemar Andre
Andrea Bazzoli (bazzo.nosp@m.li@k.nosp@m.u.edu)

Hacky (hence the name) implementation of 10r dielectric model, cutoff at 5.5A

Package Headers

This is a reimplementation of Jim Havranek's original rosetta++ Gen Born code. source files: rosetta++/gb_elec*

Author
Joaquin Ambia, Jason K. Lai
Oliver Lange (olang.nosp@m.e@u..nosp@m.washi.nosp@m.ngto.nosp@m.n.edu)
Christopher Miles (cmile.nosp@m.s@uw.nosp@m..edu)
Rhiju Das
Oliver Lange
Oliver Lange (olang.nosp@m.e@u..nosp@m.washi.nosp@m.ngto.nosp@m.n.edu)
Date
Wed Oct 20 12:08:31 2007

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 Utility 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.

Author
Vikram K. Mulligan (vmull.nosp@m.ig@u.nosp@m.w.edu)
Kale Kundert (kale@.nosp@m.thek.nosp@m.under.nosp@m.ts.n.nosp@m.et)
ashworth
Andrew Leaver-Fay (aleav.nosp@m.erfa.nosp@m.y@gma.nosp@m.il.c.nosp@m.om)
Andrew Leaver-Fay (aleav.nosp@m.erfa.nosp@m.y@gma.nosp@m.il.c.nosp@m.om)
ashworth

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 only those related to the (templated) event signaling files, those related to our smart pointer system (VirtualBase.hh and owning_ptr.hh) or that contain enums (AA.hh), typedefs (types.hh). Everything else should be forward included, or not included at all. If you find yourself adding a #include of an .hh file, stop and write Andrew an email. You are almost certainly doing something wrong.

Developed for RNA_DeNovo (farna) applications; also in use (as part of AtomLevelDomainMap) in ConstrainToIdealMover.

A lot of times we need to map dofs from fragments or from 'chunks' of library PDBs into our target pose. Its usually pretty easy to make this map by matching atom_names, but that takes time due to string lookups. This object helps cache those lookups.

In addition, the object formally holds some non-trivial mappings of chainbreak atoms (OVL1, OVL2, OVU1) to their cognate regular atoms in the pose.

Typical use case is the following:

AtomID_Mapper atom_id_mapper( reference_pose ); atom_id_mapper.renumber_after_variant_changes( new_pose ); ... desired_atom_id_in_new_pose = atom_id_mapper.map_to_reference( some_atom_id_in_new_pose );

     -- Rhiju, 2015
Author
Jonathan Weinstein (jonat.nosp@m.han..nosp@m.weins.nosp@m.tein.nosp@m.@weiz.nosp@m.mann.nosp@m..ac.i.nosp@m.l)
Frank DiMaio

Hacky (hence the name) implementation of distance dependant dielectric electrostatics, with near and far distance cutoffs.

Author
Diego del Alamo ( del.a.nosp@m.lamo.nosp@m.@vand.nosp@m.erbi.nosp@m.lt.ed.nosp@m.u )

This class is invoked when scoring. The terms that it is responsible for are fa_atr, fa_rep, fa_sol. The class is highly optimized for speed and will break if you are not careful. It calls functions within BaseEtableEnergy, which actually does the scoring. It passes an energy map, which contains the energy for that residue for the atr, rep, and sol terms. This is modified once the scores are tallied in BaseEtableEnergy.

Author
Stuart G. Mentzer (Stuar.nosp@m.t_Me.nosp@m.ntzer.nosp@m.@obj.nosp@m.exx.c.nosp@m.om) Kevin P. Hinshaw (Kevin.nosp@m.Hins.nosp@m.haw@g.nosp@m.mail.nosp@m..com) Andrew Leaver-Fay (leave.nosp@m.rfa@.nosp@m.email.nosp@m..unc.nosp@m..edu) Steven Combs - comments and skipping of virtual atoms

This class is called upon by the ScoringManager. Since actual calculating of the LJ potential is time consuming if done multiple times, this class precomputes and discritizes the potential (meaning that the potential is broken down into bins). Once the bins have been created, it will smooth out the bins, for better interpolation.

Author
Phil Bradley Andrew Leaver-Fay Steven Combs - comments and skipping of virtual atoms

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!

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!

Author
Andrew Leaver-Fay

This is an attempt to be transparent in how the orbital-hydrogen interactions were converted into a KBP. In general terms, a set of proteins from PDB were taken and the shortest distance from an orbital to a polar or aromatic hydrogen was recorded and binned. In addition to the shortest distance, an angle was taken. The angle considered is the angle between the base atom that contains the orbital, the orbital, and the hydrogen. For polar hydrogens, only sidechain polar hydrogens were considered.

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.

Author
Steven Combs
Detailed:

Defines in detail the classic motifs & submotifs that recur in RNA folding, collated from numerous sources.

TODO:

Move this into core::pose::rna. To do that, remove dependency on core::scoring::rna as following:

Maybe: Devise 'bonus' system for nice features (e.g., "canonical" sequence), but use mainly geometry to define obligate features. Depends on results of benchmarks.

Package headers C++ Headers

Package headers Utility headers Numeric headers

Author
Hetu Kamisetty
Jared Adolf-Bryfogle (jadol.nosp@m.fbr@.nosp@m.gmail.nosp@m..com)

Typedef Documentation

typedef Real core::Angle
typedef Real core::Charge
typedef Real core::Energy
typedef numeric::xyzVector< EnergyDerivative > core::EnergyGradient
typedef Real core::Length
typedef Real core::Mass
typedef float core::PackerEnergy
typedef numeric::xyzVector< Length > core::PointPosition
typedef platform::Real core::Real
typedef unsigned short core::ShortSize
typedef platform::Size core::Size
typedef platform::SSize core::SSize
typedef Real core::Trig
typedef platform::uint core::uint
typedef numeric::xyzVector< Length > core::Vector
typedef Real core::Volume