Rosetta  2020.37
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Pages
Public Member Functions | List of all members
core::chemical::rotamers::RotamerLibrarySpecification Class Referenceabstract

#include <RotamerLibrarySpecification.hh>

Inheritance diagram for core::chemical::rotamers::RotamerLibrarySpecification:
Inheritance graph
[legend]

Public Member Functions

 RotamerLibrarySpecification ()=default
 
virtual
RotamerLibrarySpecificationOP 
clone () const =0
 Create a copy of the RotamerLibrarySpecification, respecting the subclassing. More...
 
virtual std::string keyname () const =0
 Which type of SingleResidueRotamerLibrary does this specification sub-type correspond to? More...
 
virtual std::string cache_tag (core::chemical::ResidueType const &) const
 How, if at all, should the corresponding SingleResidueRotamerLibrary be cached? More...
 
virtual void describe (std::ostream &out) const =0
 Write a params-file-like description of this RotamerLibrarySpecification to the given output stream. Can be multi-line, will be ended with a newline. More...
 

Constructor & Destructor Documentation

core::chemical::rotamers::RotamerLibrarySpecification::RotamerLibrarySpecification ( )
default

Member Function Documentation

virtual std::string core::chemical::rotamers::RotamerLibrarySpecification::cache_tag ( core::chemical::ResidueType const &  ) const
inlinevirtual

How, if at all, should the corresponding SingleResidueRotamerLibrary be cached?

The default is to return an empty string, which turns off caching.

The SingleResidueRotamerLibraries are cached in the SingleResidueRotamerLibraryFactory based on keyname() and cache_tag() (as keys in a map< string, map< string, SRRL > > ). Two RotamerLibrarySpecifications with identical return values for keyname() and cache_tag() should correspond to (functionally) identical SingleResidueRotamerLibraries.

This has to be in the RotamerLibrarySpecification, as when reading we need to know the cache string before creating the library.

A note on writing RotamerLibrarySpecifications and SingleResidueRotamerLibrarys: The functions of a SingleResidueRotamerLibrary will normally have access to the actual RotamerLibrarySpecification from the passed Residue/ResidueType. Therefore, you don't need to store all the information from a RLS in the SRRL. Not doing so allows you to have more general cache_tag(), as the cache_tag() function only needs to disambiguate RotamerLibrarySpecifications which result in different SingleResidueRotamerLibrarys. (That is, cache_tag() only needs to encapsulate data used by SingleResidueRotamerLibraryCreator to create the SingleResidueRotamerLibrary.)

The ResidueType is passed to cache_tag() so that if the SingleResidueRotamerLibraryCreator needs details from the ResidueType in order to correctly create the SingleResidueRotamerLibrary, that information can be extracted. In general, though, you want to avoid keying off of information in ResidueType as much as possible.

Reimplemented in core::chemical::rotamers::NCAARotamerLibrarySpecification, core::chemical::rotamers::CenrotRotamerLibrarySpecification, core::chemical::rotamers::DunbrackRotamerLibrarySpecification, core::chemical::rotamers::PDBRotamerLibrarySpecification, and core::chemical::rotamers::BasicRotamerLibrarySpecification.

virtual RotamerLibrarySpecificationOP core::chemical::rotamers::RotamerLibrarySpecification::clone ( ) const
pure virtual
virtual void core::chemical::rotamers::RotamerLibrarySpecification::describe ( std::ostream &  out) const
pure virtual
virtual std::string core::chemical::rotamers::RotamerLibrarySpecification::keyname ( ) const
pure virtual

The documentation for this class was generated from the following file: