February 2008 - IMP-dev

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

ConnectivityRestraint
by Daniel Russel 12 Feb '08

12 Feb '08

Here is a new connectivity restraint and some simple tests. The following code needs to be added to IMP.i also %pythonprepend ConnectivityRestraint::ConnectivityRestraint %{ args[0].thisown=0 %}

1 0

active particles and their restraints
by Friedrich Foerster 12 Feb '08

12 Feb '08

hi all (i.e. ben & daniel), i tried to deactivate particles and optimize only selected parts of a model. when using the em restraint i observed an oddity: restraints are not evaluated, if ONE particle in the set is not active. i do not think this is a sensible thing, for example my em restraint was not evaluated at all... i attached a patch where a restraint is omitted only if ALL particles are inactive. if you agree that it makes more sense, please commit it to imp. best frido -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Friedrich Foerster % % Andrej Sali Lab % % University of California at San Francisco % % MC 2552 % % Byers Hall Room 501 % % 1700 4th Street % % San Francisco, CA 94158-2330, USA % % % % phone: +1 (415) 514-4258 % % fax: +1 (415) 514-4231 % % % % www.salilab.org/~frido % % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Index: kernel/src/Restraint.cpp =================================================================== --- kernel/src/Restraint.cpp (revision 349) +++ kernel/src/Restraint.cpp (working copy) @@ -67,12 +67,12 @@ IMP_assert(get_model() != NULL, "Add Restraint to Model before calling check_particles_active"); are_particles_active_ = true; + int icount=0; for (size_t i = 0; i < particles_.size(); i++) { - if (!get_particle(i)->get_is_active()) { - are_particles_active_ = false; - return; - } + if (get_particle(i)->get_is_active()) icount = icount + 1; } + // return false only if ALL particles are deactivated in restraint + if (icount ==0 ) are_particles_active_ = false; } } // namespace IMP

3 7