March 2008 - IMP-dev - salilab.org

Harmonic cleanup
by Daniel Russel 01 Apr '08

01 Apr '08

Here is my version of the harmonic. It removes the internal scaling factors since those only make sense given various assumptions about the system. Instead offers a function which allows you to compute the spring constant from a standard deviation (and a temperature) if you want those assumptions to hold. This way harmonic can be used to construct more complicated potentials as well as to mimic modeller/ charm if desired. No existing code meaningfully depended on the old behavior. The test code has been patched.

3 11

Names for particles
by Daniel Russel 01 Apr '08

01 Apr '08

From discussions with Karin :-) concerning IO: - It is probably worthwhile to have a name for each particle which uniquely identifies the particle. The ID doesn't really serve this purpose as adding a particle changes the ids of particles which are added later. My proposed mechanism would look something like like adding get and set name methods to particles (and perhaps an argument to the constructor). When a particle is added to a model, if there is a name conflict then an exception would be thrown (or we could append something to the name to make it unique). If no name was specified before the particle is added to the Model, a unique name would be generated ("particle 3"). These names mean that logging and XML-based IO could use something nicer and more stable to identify particles. And logging could print names instead of particle ids since the names are always non-empty and meaningful.

3 3

IO support with boost
by Daniel Russel 28 Mar '08

28 Mar '08

I was just checking out the boost serialization library. It looks like the simplest way to get code to save and restore the model state. It also supports XML io, so you can relatively easily generate an XML file. This makes it pretty useless in terms of human readability. To read and write a DistanceRestraint using the library you just add code like template <class Archive> void serialize(Archive &ar, const unsigned int version) { ar &boost::serialization::base_object<Restraint>(*this); ar &boost::make_nvp("scorefunction", sf_); } in addition, we need the macro "BOOST_CLASS_EXPORT(DistanceRestraint)" so it gets the names right. That is pretty awesome as there is only one chuck of code, so there is less to keep synchronized. It has support for stl containers so those get trivially serialized too.

3 3

Cleanup up version of last patch
by Daniel Russel 28 Mar '08

28 Mar '08

I cleanup up the score states patch slightly to remove the constructors omitting the radius since I think the case of point-like particles is rare enough that we should make people think a bit to make sure they really do want to ignore radii.

1 0

nonbonded list cleanup
by Daniel Russel 28 Mar '08

28 Mar '08

Since no one had any good reasons to keep the non-sphere version of the nonbonded lists around, I removed them while I was making various changes. The other change I made is a added slightly more clever than before quadratic nonbonded lists (I think we want these at least for testing purposes). In addition, the constructors have been rearranged so that various things are optional since I often want to construct the states without knowing the full set of particles. API changes: AllSphereNonbondedListScoreState is now AllNonbondedListScoreState and the radius key is first, if used. BipartiteNonbondedListScoreState now uses a dumber algorithm, but supports radii. I can move it back to a grid based implementation later. As a trivial change, i fixed an indentation issues in bond_decorators.h

1 0

unary function checks
by Daniel Russel 27 Mar '08

27 Mar '08

I added some python code to check that the derivative matches (more or less) the slope of the values on a unary function. Currently this is just applied to harmonic, which is not extremely useful (but I do use it on other not-yet submitted unary functions).

2 6

WLC unary function
by Daniel Russel 27 Mar '08

27 Mar '08

I have a unary function which implements the worm-like-chain model for polymers. Do people think that such sorts of functions should go in to IMP? I would lean against it as too domain specific.

2 1

units
by Daniel Russel 26 Mar '08

26 Mar '08

As I was running in to issues converting units for handling various bits of data I wrote some classes to help. I have one class for MKS units and one for the KCal/Mol/Angstrom sorts of units that MD expects. And methods to handle conversions between the two. Using them you can write things like PicoJoules(1)/Meter(2) and get something with the right units out and then call convert_to_kcal to convert it to the MD units. Perhaps the latter unit should be called MDUnit or something. It is written as C++ template classes but specific units can probably be exposed to python. However I think Scientific Python already includes this sort of thing, so it is probably not very useful. However, that means there is no easy way to test any of it with our current test framework. Since it is written using templates, there is no easy way to integrate it into the attribute table. So don't get any ideas about that, as nice as it would be. On the plus side, there is no runtime penalty. It is used in the soon-to-be-submitted brownian dynamics code among other things.

2 1

Various small IMP patches
by Daniel Russel 26 Mar '08

26 Mar '08

Added a comment to the attribute table about future optimizations Added a comment about what the various levels of logs should mean. cleaned up logging in model a bit. minor cleanups in the optimizer state base class Minor cleanups to particle in regards to IO. ParticleGrid uses the XYZDecorator::get_xyz_keys() Comment about logging in restraints minor cleanup and comment about logging in score states

1 0

Nonbonded lists
by Daniel Russel 25 Mar '08

25 Mar '08

Does it makes sense to have sphere and non-sphere versions of nonbonded lists (ones with and without non-zero radii)? I know there are contexts where you can get away with the latter, but it seems like we mostly want spheres and the added confusion and maintenance burden might overwhelm the advantage. Thoughts? I don't see myself using the non-sphere version. If the radii are zero, the difference comes down to fetching a zero attribute and adding it to each radius. And making sure that each particle has such an attribute.

4 8