IMP-dev January 2008

imp-dev@salilab.org

2 participants
12 discussions

Missing virtual functions
by Daniel Russel 29 Jan '08

29 Jan '08

On my machines the test suite complains that a couple of the restraints defined in python are missing the virtual functions for version and last_modified_by. This patch adds those. On a separate note, it is not clear to me that anyone will ever bother to actually update these fields. Especially since they are defined primarily in the headers and code changes are most likely to occur in the .cpp files. Is it possible to use a SVN hook to update them automatically?

2 2

Re: [IMP-dev] Various small patches
by Ben Webb 25 Jan '08

25 Jan '08

Daniel Russel wrote: > My thought for an improved implementation was to throw the points into a > voxel grid and then have an iterator which traverses the voxel grid and > generates pairs on the fly (rather than generating and storing them). Well, that sounds essentially like a cell-based nonbonded list, which is the most common good way of implementing a nonbonded list (and is what Modeller does) except for the bit about generating pairs on the fly. > How far the iterator searches for the second point for each voxel would > be determined by the distance cutoff. It seems easy enough to implement. The trick is choosing the voxel size sensibly, akin to choosing a hash bin size. This is a bit trickier if you have multiple iterators with different cutoffs. BTW, another thing to be aware of is that most MM force fields (including CHARMM) exclude not just 1-2 pairs (bonds) but also 1-3 and 1-4. But I guess it would be pretty straightforward to exclude those pairs too by following the bond graph. 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

Various small patches
by Daniel Russel 25 Jan '08

25 Jan '08

Here are a bunch of conceptually separate patches. They are unlikely to work entirely separately in practice due to external things like IMP.{ih} and SConscript files and test cases tying them together. The first cleans up the BondedListScoreState by deleted some commented out code adding a comment and adding a set_particles method to go along with the corresponding method in nonbonded list. The next updates the nonbonded list in two ways. First it is refactored so that the internals can be reused by other states (namely a BipartiteNonbondedListState I use) and secondly the distance threshold belongs in the iterator, not in the constructor as different restraints may have different thresholds. It is not currently used as the internal implementation is dumb, but we should try to converge on the desired interface anyway. Corresponding changes are made to the NonbondedRestraint I added a preliminary implementation of a BondedList which uses the bond decorator definition of a bond. It comes with a restraint which uses length and spring constant info stored in the bond particle to restrain the bond. We probably want to revisit what is stored in the bond (in light of the discussions concerning the Harmonic). Finally, the aforementioned bipartite nonbondedlist. It only returns pairs which cross two sets of particles. It seemed worth having such a class as it can be implemented much more efficiently than just having filters on top of the regular nonbonded list. And it is little code until then.

2 1

Harmonic oddities
by Daniel Russel 22 Jan '08

22 Jan '08

Now that I actually tried to use it, I find the Harmonic class a bit odd. For one thing the parameter is called "standard deviation" or something, which doesn't mean anything for a harmonic. Secondly, once you figure out what it is, it is multiplied by a many significant figure constant before it is used (the documentation says this is for modeller compatibility). This multiplier makes it very hard to use the Harmonic as part of a scoring function (since it is hard to make the composite function continuous). Do we really want this? In my mind the thing that makes the most sense is to to have a the mean and the spring constant be the parameters and to get rid of the odd multiplier.

2 2

documentation suggestion
by Daniel Russel 18 Jan '08

18 Jan '08

The IMP doxygen documentation currently throws a lot of class and function names in your face in no particular order (well, alphabetical, but no conceptual order). We can use doxygen modules to give it a nicer structure. This patch adds a module for logging and another for error checking. I think they help a lot. We probably want ones for - Restraints - Optimizers - States - The kernel - Decorators - random helpers - internal stuff To create a module put a \defgroup id Pretty name with spaces in some doxygen comment and to add something to one put a \ingroup id in the objects commnets

2 1

Bonded restraint
by Daniel Russel 17 Jan '08

17 Jan '08

This patch adds a restraint for bonded particles using information created by the bond decorators. Currently you must use the decorator to set the length for each bond.

2 1

Refactored distance computations
by Daniel Russel 17 Jan '08

17 Jan '08

I pulled the basic distance pair score computation into an internal function defined DistancePairScore.h. This function takes an offset and a scale, so the SphereDistancePairScore, DistancePairScore and bond restraints can all use it internally.

1 0

Nonbonded list
by Daniel Russel 15 Jan '08

15 Jan '08

This patch adds a non-bonded list. The implementation is dumb, but functional. The code more or less follows what was discussed earlier on the list. There is also a NonbondedRestraint which applies a PairScore to each nonbonded pair. There are PairScores for distance between the centers of the two particles and distance between the two spheres. The DistanceRestraint now uses the DistancePairScore internally to remove redundant code. There is some trivial testing.

1 0

Minor cleanup to bonds
by Daniel Russel 11 Jan '08

11 Jan '08

I cleaned up the bond decorator code. Among other things I removed the length parameter with the expectation that I will add another similar set of decorators for custom connectors (not quite sure what to call them). These will represent arbitrary length attachments between particles. I also added some test code for the bond decorators. The connectors will have a length and stiffness parameter and will be handled all together by a restraint (along the lines of what was discussed with the non-bonded list). Normal inter-atomic bonds could be handled by generating the appropriate lengths from the names of the atoms involved in each atomic bond and adding the connector information.

1 0

Re: [IMP-dev] minor quibble
by Ben Webb 11 Jan '08

11 Jan '08

Daniel Russel wrote: > It probably better to call it UnaryFunction rather than UnaryFunctor as > unary functors already mean something more general in C++ (any functor > that takes one variable). I guess strictly speaking it should be > UnaryRealFunction, but we can get elide the Real. Fair enough; as of r319 they are UnaryFunctions. 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev January 2008