- IMP-dev - salilab.org

Cleanup of grid
by Daniel Russel 13 Feb '08

13 Feb '08

moved the indexes into the IMP namespace since some people will want to use them and added comments. Index: kernel/include/IMP/Grid3D.h =================================================================== --- kernel/include/IMP/Grid3D.h (revision 360) +++ kernel/include/IMP/Grid3D.h (working copy) @@ -17,12 +17,13 @@ template <class V> class Grid3D; -namespace internal -{ - template <class GI> class GridIndexIterator; +//! Represent an index into an infinite grid +/** The index entries can be positive or negative and do not need to correspond + directly to cells in the grid. They get mapped on to actual grid cells + by various functions*/ class VirtualGridIndex { typedef VirtualGridIndex This; @@ -31,6 +32,7 @@ return d_[0]==std::numeric_limits<int>::max(); } public: + //! Create a grid cell from three arbitrary indexes VirtualGridIndex(int x, int y, int z) { d_[0]=x; d_[1]=y; @@ -39,6 +41,7 @@ VirtualGridIndex() { d_[0]=d_[1]=d_[2]=std::numeric_limits<int>::max(); } + //! Get the ith component (i=0,1,2) int operator[](unsigned int i) const { IMP_assert(i <3, "Bad i"); return d_[i]; @@ -54,9 +57,14 @@ IMP_OUTPUT_OPERATOR(VirtualGridIndex); +//! Iterate through grid cells in a cube +/** The order of iteration is unspecified. + */ template <class GI> class GridIndexIterator { + template <class V> + friend class Grid3D; VirtualGridIndex lb_; VirtualGridIndex ub_; GI cur_; @@ -64,18 +72,19 @@ bool is_default() const { return false; } + GridIndexIterator(VirtualGridIndex lb, + VirtualGridIndex ub): lb_(lb), + ub_(ub), cur_(lb[0], lb[1], lb[2]) { + IMP_assert(ub_.strictly_larger_than(lb_), + "Invalid range in GridIndexIterator"); + } public: typedef const GI& reference_type; typedef const GI* pointer_type; typedef GI value_type; typedef std::forward_iterator_tag iterator_category; typedef unsigned int difference_type; - GridIndexIterator(VirtualGridIndex lb, - VirtualGridIndex ub): lb_(lb), - ub_(ub), cur_(lb[0], lb[1], lb[2]) { - IMP_assert(ub_.strictly_larger_than(lb_), - "Invalid range in GridIndexIterator"); - } + GridIndexIterator(){} IMP_COMPARISONS_1(cur_); @@ -118,9 +127,11 @@ } }; -} // namespace internal - -class GridIndex: public internal::VirtualGridIndex +//! Represent a real cell in a grid +/** These indexes represent an actual cell in the grid with no mapping. + They can only be constructed by the grid. + */ +class GridIndex: public VirtualGridIndex { public: GridIndex(): VirtualGridIndex() { @@ -129,7 +140,7 @@ template <class V> friend class Grid3D; template <class G> - friend class internal::GridIndexIterator; + friend class GridIndexIterator; GridIndex(int x, int y, int z): VirtualGridIndex(x,y,z) { IMP_check(x>=0 && y>=0 && z>=0, "Bad indexes in grid index", IndexException("Bad indexes in GridIndex")); @@ -152,7 +163,7 @@ /** Such an index can refer to voxels outside of the grid or with negative indices. */ - typedef internal::VirtualGridIndex VirtualIndex; + typedef VirtualGridIndex VirtualIndex; private: std::vector<VT> data_; @@ -342,7 +353,7 @@ /** The iterator iterates though the valid indexes bounded by the VirtualIndex */ - typedef internal::GridIndexIterator<Index> IndexIterator; + typedef GridIndexIterator<Index> IndexIterator; IndexIterator indexes_begin(VirtualIndex lb, VirtualIndex ub) const { std::pair<Index, VirtualIndex> bp= intersect(lb,ub);

1 0

AnglesRestraint
by Daniel Russel 13 Feb '08

13 Feb '08

I think it would be good to have an AnglesRestraint which stores a list of chains and applies an AngleRestraint-like restraint to each triple in each chain. It is easier to set up and maintain than a whole mess of AngleRestraints and more efficient too. Comments? //! Restraint the angles between particles /** Currently the particles can be added as chains and the angle of each three successive particles in the chain is restrained. \ingroup restraint */ class IMPDLLEXPORT AnglesRestraint : public Restraint { public: //! Create the angle restraint. /** \param[in] score_func Scoring function for the restraint. */ AnglesRestraint(UnaryFunction* score_func); virtual ~AnglesRestraint(){} IMP_RESTRAINT("0.5", "Daniel Russel"); //! Add a chain of particles /** Each three successive particles are restrained*/ void add_chain(const Particles &ps); //! Clear all the store chains void clear_chains(); protected: std::auto_ptr<UnaryFunction> score_func_; std::vector<int> chain_splits_; };

2 2

Angles restraint
by Daniel Russel 13 Feb '08

13 Feb '08

I implemented a collective version of the AngleRestraint. It maintains a bunch of chains (more interesting topology can be added later) and applies the same unary function to each angle along each chain. As before, SConscript etc are not included. %pythonprepend AnglesRestraint::AnglesRestraint %{ args[0].thisown=0 %}

3 3

kernel/src/doc
by Daniel Russel 12 Feb '08

12 Feb '08

Why is it there rather than in kernel/doc? Is it used? Especially since there is not much reason otherwise to have doxygen parse kernel/ src (since such files don't define the API).

1 0

Pulling out the macros
by Daniel Russel 12 Feb '08

12 Feb '08

It appears that we don't need to have separate copies of the macros in the IMP_macros.i. I have pulled the macros out into separate headers which are then %included into that file.

1 0

pdb patch
by Daniel Russel 12 Feb '08

12 Feb '08

This patch makes IMP get the atom name from the right modeller field.

2 1

Nonbonded list try 2
by Daniel Russel 12 Feb '08

12 Feb '08

Here is the next crack at submitting the nonbonded list. Something is undoubtedly missing. The changes since the last submission include - the grid is now updated lazily. A MaxChangeScoreState is used to accomplish this. That class just keeps track of the max change of a set of variables - various bugs have been fixed Already forgot something These changes to IMP.i may or may not be needed %pythonprepend NonbondedListScoreState::add_bonded_list %{ args[1].thisown=0 %} %pythonprepend NonbondedRestraint::NonbondedRestraint %{ args[1].thisown=0 %} %pythonprepend BondDecoratorRestraint::BondDecoratorRestraint %{ args[1].thisown=0 %}

1 0

MonteCarlo
by Daniel Russel 12 Feb '08

12 Feb '08

Keren was interested in Monte Carlo optimization, so I thought I might submit the one I wrote. It is structured as an optimizer coupled with a set of Movers which propose moves. The optimizer holds a collection of Movers and a local optimizer (which can be used to mix local optimization with monte-carlo). Current movers take a set of particles and a set of attributes and perturb all of those attributes on each of the particles either uniformly in a a ball or with a normal distribution. A class called MoveGuard keeps track of the information necessary to revert if the monte carlo step is rejected. Note that as it stands, writing a Mover in Python would take noticeably more work as the macro does a good bit of work. As a note, my current implementation uses the boost random number library. I think we should probably make boost a required dependency since - it is really useful (I could easily write better iterators for various things) - all linux systems have builds these days (mostly installed by default) and we distribute mac and windows binaries (and the important boost bits are header-only affairs)

2 1

default constructor on vector3d
by Daniel Russel 12 Feb '08

12 Feb '08

1 0

ListRestraint
by Daniel Russel 12 Feb '08

12 Feb '08

Here is a restraint which applies a singleton score to a list of particles. There is also a singleton score which acts on the distance to a fixed point. This restraint should probably replace the SphericalRestraint. %pythonprepend ListRestraint::ListRestraint %{ args[1].thisown=0 %} %pythonprepend DistanceToSingletonScore::DistanceToSingletonScore %{ args[1].thisown=0 %}

1 0