Decorator for switching spring functions based on a matrix of flags. More...
|BoundSuperBlock (SuperBlock *b, SpringFunction *bs, loos::Math::Matrix< int > &cm)|
|loos::DoubleMatrix||block (const uint j, const uint i)|
|Returns a 3x3 matrix representing a superblock in the Hessian for the two nodes. |
|SpringFunction::Params||setParams (const SpringFunction::Params &v)|
|Assign parameters and propagate to the decorated superblock. |
|bool||validParams () const|
|Both the alternate and all decorated parameters are valid. |
|uint||paramSize () const|
|Returns the aggregate parameter size. |
|Public Member Functions inherited from ENM::SuperBlockDecorator|
|SuperBlockDecorator (SuperBlock *b)|
|Constructor that takes a SuperBlock to decorate. |
|Public Member Functions inherited from ENM::SuperBlock|
|SuperBlock (SpringFunction *func, const loos::AtomicGroup &nodelist)|
|Constructor taking a spring function and a list of nodes. More...|
|SuperBlock (const SuperBlock &b)|
|uint||size () const|
|Protected Member Functions inherited from ENM::SuperBlock|
|loos::DoubleMatrix||blockImpl (const uint j, const uint i, SpringFunction *fptr)|
|Implementation of the superblock calculation. More...|
|Protected Attributes inherited from ENM::SuperBlockDecorator|
|Protected Attributes inherited from ENM::SuperBlock|
Decorator for switching spring functions based on a matrix of flags.
The following is a decorator for SuperBlock that implements an alternative set of spring constants for nodes that are "bound" together. The constructor takes a SuperBlock to decorate, along with a pointer to the alternative SpringFunction and a matrix of ints representing the connectivity (i.e. 1 if two nodes are connected, 0 otherwise).
A few notes about using decorators... The idea behind a decorator is that you add layers (or decorate) to a class by combining multiple decorators. For example, suppose you have two different kinds of connectivity you want to represent in a Hessian. You would set-up your SuperBlock like,
You now always work with the last decorated object, i.e. side_chained. When side_chained->block() is called, it first checks to see if the nodes represent a side-chain bond. If so, that spring function is used. If not, then it passes control to the object it decorates, i.e. backboned. Backboned now checks to see if the nodes represent a backbone bond. If so, it uses that spring function. If not, then control is passed to the inner unbound SuperBlock which uses its spring function.
This method has two important caveats. First, the calculation is now order-dependent. If, for some reason, you have nodes that are listed as both side-chains and backbones (for a contrived example), then the one used will depend on the order in which the SuperBlock was decorated. The second caveat is that we are using real, raw pointers here, so be careful about cleaning up to avoid memory leaks and also keep in mind that the intermediate pointers (i.e. backboned) are contained within the higher-level decorators. So, do NOT delete any of the intermediate steps until you are sure you are done with everything.