July 2011 - IMP-dev - salilab.org

proposal to simplify implementation of collections of decorators and particles
by Daniel Russel 05 Aug '11

05 Aug '11

Currently, lists of decorators and particles in IMP are implemented using some rather complicated an brittle custom containers and a reasonable runtime cost for iterating through Particles and Decorators. I would like to remove this code and replace the implementations by plain std::vectors (and std::vector<Pointer> when reference counting is needed). This would result in no difference to the python API, which does not use these containers at all. On the C++ side, there would be some significant changes, in particular - atom::Hierarchies would no longer inherit from core::Hierarchies and core::XYZRs would no longer inherit from core::XYZs, so certain code which assumes an implicit conversion from one to the other would break. Fixing the code would require addding IMP::get_as calls and a copy, or, ultimately better, just storing Particles and ParticlesTemp objects and constructing the decorators on demand - Particles no longer would inhertit from ParticlesTemp, so similar implicit conversions from one to the other would need get_as calls (which would result in a copy). From perusing the code, most of these conversions are occur in places when a Particles could be replaced by a ParticlesTemp with no loss of functionality (and a marginal speedup). These changes are likely to require many straight forward changes to existing code. So I'm a bit ambivalent.

2 2

Another proposed mover change
by Daniel Russel 30 Jul '11

30 Jul '11

I'd like to make another minor change to the mover, namely to change the propose_move method so that it returns a list of particles that were moved. Monte Carlo implementations can then use this list to only evaluate the restraints whose scores have been changed, replacing the functionality that was removed when the incremental evaluation support was removed. I will, of course, make the changes for movers in svn.

1 0

Proposed change to Movers
by Daniel Russel 27 Jul '11

27 Jul '11

I'd like to move the MoverBase-based movers off of SingletonContainers :-). This would simplify their implementation, make running with them slightly more efficient, as well as simplifying their usage as. It would also harmonize the various movers a bit. And, of course, it would break various existing code. I could provide a backward compatibility functions, but I am reluctant to do that as providing the functions is a bit complicated and the semantics have changed (that is the particles are no longer shared) and, while I don't expect the changed semantics will make any difference to anyone, I would rather people inspect their code just to be sure. So the new constructors for the BallMover and NormalMover would be BallMover(ParticlesTemp particles, FloatKeys dofs, double radius). or BallMover(ParticlesTemp particles, double radius). This will also remove some of the direct accesses to the contents of containers to move towards supporting filters on the all pairs containers and such things.

1 0

proposal to narrow container interfaces
by Daniel Russel 25 Jul '11

25 Jul '11

Right now, containers in IMP (ie SingletonContainer, PairContainer), support looking at the particles via (for a SingletonContainer) 1) get_particles() 2) iterate through the particles 3) a for loop on the indexes and using get_particle() 4) applying a SingletonModifier or SingletonScore 2 and 3 are quite limiting and effectively eliminate the ability to use containers where it is non-trivial to predict how many items the container will contain without generating them all. More concretely, it eliminates the possibility of using filters with the AllPairContainer and other similar containers (or at least makes it very difficult). I would like to remove 2 and 3. No python code is likely to be affected as it probably all uses the get_particles() equivalebts and I can fix all the code in IMP svn (which most likely uses 3). How much would such a change be likely to affect people? To get an idea, search for get_numer_of_particles() and get_number_of_particle_pairs() in your c++ code. Thanks.

1 0

proposed imp dev meeting on coarse grained models and pdb
by Daniel Russel 05 Jul '11

05 Jul '11

Lots of people have been bumping into the fact that it is kind of annoying to handle the following sort of work flow: - read a pdb - create a coarse grained rigid model - move the coarse grained rigid model around (ignoring the atoms as much as possible, for efficiency) - write an appropriately transformed version of the pdb The problems are: - doing this reliably requires you saving the initial transformation of the rigid body and then transforming the components of the initial pdb by the difference between the initial and final. There are lots of plausible seeming ways of doing the job that don't work reliably. - less troublesome, creating all the particles for a large pdb can take a bit of time I'm not sure of a way of providing a simple interface to this that is easy to implement reliably. And so I thought it might be worth having a brainstorming session/discussion on the topic to see if we can come up with a nice, canned solution. Interested? Some possible bits of solutions are: - IMP::atom::create_rigid_body can store the initial transform internally and provide a method to get how much the molecule moved - the hierarchy clone method could keep a link back to the hierarchy it was created from to help you in going back (if you want to keep the whole hierarchy in memory) - we could provide a single method that transforms a pdb file without creating particles from it

1 0