December 2007 - IMP-dev

change IMP.ParticleVector to IMP.Partcles
by Daniel Russel 17 Dec '07

17 Dec '07

to be consistent with everything else (I don't like having the name Vector in python code as it acts like a python list). And the name Particles is already used for it in C++. Changed the distance test case to use it.

1 0

Add square function
by Daniel Russel 16 Dec '07

16 Dec '07

I added a template function square to utility.h which computes the square of any object. In order to make sure it gets tested I cleaned up the implementation of DistanceRestraint and made it use the square function. Since python has the ** operator already, I don't see any reason to export this function to python at the moment.

1 0

Re: [IMP-dev] Update SphericalRestraint
by Ben Webb 16 Dec '07

16 Dec '07

Daniel Russel wrote: > I think we may want to think about removing the list of particles from > the Restraint base class and providing several restraint subclasses > which use different containers to store the particles (this would be a > fairly minor change given the IMP_RESTRAINT macro and the current > interface). Then, we could have restraints which require a dynamic set > use a std::set, and ones which just have a static list or (like distance > restraint) a fixed number, use a vector or just member variables. Agreed - although I suggest there's little point in doing that unless we have specific restraints in mind which need such functionality. > I have ended up rolling my own version of ExclusionVolume. I have a > version which either enforces excluded volume, or, if the particles are > bonded, enforces the bond (it uses the BondDecorator def of bond). I > suspect something on those lines will be more useful in the long run as > we rarely have a set of particles where nothing is interacting tightly. As you mention elsewhere, this is probably pretty slow. The usual way of doing such a thing efficiently (at least in molecular mechanics packages) is to have two restraints - one is the stereochemical restraint, a simple loop over all bonds (in the Modeller case, this is done just once and restraints are set up for each bond) while the second is the excluded volume restraint, a loop over all nonbonded pairs. Part of the nonbonded pair generation mechanism excludes bonded particles. Ben -- ben(a)salilab.org http://salilab.org/~ben/ "It is a capital mistake to theorize before one has data." - Sir Arthur Conan Doyle

2 3

[Fwd: Build system failure, 12/16/2007]
by Ben Webb 16 Dec '07

16 Dec '07

Looks like Daniel's static variable initialization check caught some badness on IMP Windows builds (see below; the x86_64 build also failed, but I suspect that's an intermittent NFS issue). Patches to fix this are welcomed. ;) P.S. I suspect most of you don't have access to a Windows box with MSVC and scons installed. So to build IMP with MSVC, build it on synth and pass 'wine=true' to your scons invocation. That'll run the MS tools on Linux using Wine. Ben -------- Original Message -------- Subject: Build system failure, 12/16/2007 Date: Sun, 16 Dec 2007 07:00:02 -0800 From: build-system(a)salilab.org To: ben(a)salilab.org Build system failed on 12/16/2007. Please see https://salilab.org/internal/imp/tests.html for full details. -- ben(a)salilab.org http://salilab.org/~ben/ "It is a capital mistake to theorize before one has data." - Sir Arthur Conan Doyle

1 0

First significant code review
by Daniel Russel 14 Dec '07

14 Dec '07

I changed the interfaces of DistanceRestraint and ExclusionRestraint to make them more consistent and more general. Warning, it is quite long due to many similar changes in the test cases. Yeah for sed, but I wouldn't want to read through the diff :-) DistanceRestraint now takes a pair of ParticleIndexes and a ScoreFunc which it then owns. I also removed the constructor with a passed radius as that does add any power and adds another path which has to be tested and maintained. ExclusionRestraint takes a list or lists of ParticleIndexes (instead of ints). Various unused member variables are removed. Restraint::show now has a default argument so it can be called from python. Applying it requires first applying the decorators patch I sent before (since I removed the redundant creation of the FloatKeys in DistanceRestraint). It might also require the more minor kernel patch also included.

2 6

SphereRestraint
by Daniel Russel 14 Dec '07

14 Dec '07

This diff removes CoordinateRestraint and adds SphereRestraint which restraints a point's distance to a fixed point. It also makes the vectori to Int change. The XYZ decorators patch is also attached again as the previous version didn't quite split things right (I had needed to add methods to Particle.h to changed the optimized status of a float).

2 4

Changing vectori vectorf
by Daniel Russel 14 Dec '07

14 Dec '07

I propose we change IMP.vectori and IMP.vectorf to IMP.Ints and IMP.Floats to be consistent. Any objections?

3 3

Minor changes to xyzdecorator
by Daniel Russel 14 Dec '07

14 Dec '07

Here are some minor changes to the XYZDecorator. It now always creates the keys since we are always using the. This means that the get_coordinate_key(i) method doesn't have to check when getting the keys out. It also has methods to change whether the particle is optimized or not. These methods are checked as part of the SphereRestraint patch I will submit separately.

1 0

CoordinateRestraint
by Daniel Russel 14 Dec '07

14 Dec '07

It seems entirely useless to me as written as it can only restrict coordinates relative to the origin. I propose getting rid of it and instead providing, as needed, SphericalDistanceRestraint (restraint the distance from a fixed point), CoordinateRestraint (which restricts a coordinate relative to a fixed value) etc. The names could use some work. My suggestion for SphericalDistanceRestraint (which is what I want) is: SphericalDistanceRestraint(Model*, ParticleIndex (or Particle*), Float x, Float y, Float z, ScoreFunc *f); Then you can enforce any spherically symmetric restraint on a set of particles (in my case enforcing that they are all in some sphere bounding the system).

2 4

Re: [IMP-dev] Fix behavior of DistanceRestraint at near-zero distance
by Ben Webb 13 Dec '07

13 Dec '07

Daniel Russel wrote: > Fine with me with a few comments. > > I don't know that counting on pre-optimization perturbation is > reasonable as a degeneracy could arise during an optimization. That > said, in most cases, other forces should cause the two particles to > diverge even if the degenerate distance restraint does not. Agreed. The probability of two particles ending up in exactly the same position is rather small (unless you have a force pulling them together). > In Bret's defense, his code returned random derivatives, not a random > score as he snapped the distance to the minimum. You are, of course, exactly correct. Ben -- ben(a)salilab.org http://salilab.org/~ben/ "It is a capital mistake to theorize before one has data." - Sir Arthur Conan Doyle

1 0