[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IMP-dev] Deactivating particles



The way I have implemented things I produce a number of unused (deactived) particles as I create and destroy bonds. I would like to be able to recycle them. I think this is a general problem, so it is probably worth some discussion.

The sort of solution is to have a static map in bond_decorator.cpp (actually graph_decorators.cpp) which maps from Model* to unused bond particles and reuses particles if they are available. This is only sort of a solution since if a Model is destroyed I can't know to clean out the particle pointers and if a new model is created with the same address, then I will try to use pointers to invalid memory.

There are a couple complicating points for a general solution:
1) we want particles in the model to be addressable by index quickly and the index needs to be convertible into an int. 2) we want to be able to keep dead particles around for debugging purposes to make sure restraints are kept up to date

In order to handle (1) with deletions we could do one of
- set entries in the Model::particles_ vector to be NULL when the particles are deleted and have the iterators skip them. The get_particles() method for python would then have to copy out the valid particles pointers. It is just for python and not generally useful, so this may be a small cost. - implement and use a map or hash map instead of a vector for storage and make sure everything works with python - maintain a dense vector and have get_particle use binary search. This makes deletions slow but would be very easy to implement.

Point (2) could be handled via reference counting. Since particles won't be extended in Python, (except for the evil XYZParticle or whatever it is called), reference counting can relatively easily be made to work, if I recall my earlier experiments correctly). Since we use the IMP::Particles alias most everywhere we store particles, this wouldn't require too many code changes.

Any thoughts?

Irrespective of anything here, the python XYZParticle should probably go away as it results in code that breaks on particles which have x,y,z but happen not to be actual instances of XYZParticle.