IMP-dev

imp-dev@salilab.org

869 discussions

IMP patches
by Daniel Russel 09 Apr '08

09 Apr '08

First some minor cleanups - adding operator<< to Vector3D and fixing some header inclusion issues Second adding particle removal as previous discussed: - There is a new base class RefCountedObject which is used for Particle and is ref counted. Vector and ObjectContainer ref count ref counted objects that are contained in them - particles now have a Particle attribute type - the usual caveats about changes to SConscript files being ignore and IMP.i containing some extra changes apply (extra %includes) - if a particle is removed from the model it is made inactive also. We should probably have the particle constructor make the particle inactive until it is added to a model. Bonds use the Particle attribute: - no visible changes Hierarchy uses the particle attribute - no visible changes The nonbonded list is more dynamic: - it drops inactive particles silently - you can add particles and they are handled correctly, if not terribly efficiently I can't guarantee that the patches all work independently

1 0

deactivating particles
by Daniel Russel 08 Apr '08

08 Apr '08

To make my previous email more concrete (and revise things slightly), deactivating particles would involve: - telling the Model to delete the particle. That removes the pointer in the model and frees the index up to be recycled - the ParticleIterators in the model skip delete particles (skip null pointers) - the particle is marked as invalid and any accesses to it throw exceptions - all pointers to the particle are reference counted and the particle object is deleted when all of them go away A slightly more complicated alternative which would delay recycling ParticleIndexes would be - marking them as inactive - The Model ParticleInterators skip inactive (and NULL) particles. Python people will just have to deal unless someone knows how to get custom iterators working in python - all pointers held by restraints are reference counted. When all of the pointers held by everything go away, the Particle entry is set to NULL in the model (and can be reused) and the particle is deleted. - the Model maintains a list of free particle indexes and reuses them once they are gone from the system These proposals leave open the issue of making sure that particle indexes stored in the attribute table always point to the right generation of particle (i.e. make sure that the index doesn't get recycled before they get cleaned up). One solution to this would be to add a new attribute type, that of a particle pointer so these have full reference counted semantics. This would not be hard.

3 2

Inactive particles
by Daniel Russel 08 Apr '08

08 Apr '08

What is means for a particle to be inactive is not well defined at this point. My proposal would be that we define them to be permanently dead-- particles are made inactive by removing them from the Model. When restraints encounter inactive particles, they should either: - if they act on bulk sets of particles, just remove the inactive particle from their list and go on. This would apply to the nonbonded list and list-based restraints - if they act on a constant number of particles, the InactiveParticleException should propagate. The thing holding the restraint can use the exception to destroy the restraint (maybe) or, probably better, just to kill the optimization. The iterators provided by the model would skip inactive particles (and reference counting would ensure that the memory is reclaimed when everything is cleaned up), thereby allowing the optimizers to work when there are inactive particles. Using this, you could, for example, maintain a dynamic set of particles by adding all new particles to the nonbonded list and know that all inactive particles will get cleaned up properly. In order to make sure the reference counting works, Particles would get a new attribute type which is a pointer to another particle. Bonds and hierarchies would use this new attribute type. Note that swig reference counting is pretty much useless, so there is no trivial way to ensure that all references held in python keep the respective bit of memory alive. Namely, if you get a particle back from the model or a restraint, this python object will not keep the corresponding C++ object alive. There are solutions to this problem, but I don't want to implement them now as they are a bit complicated. For now, the best solution might be to have the python wrapper print warnings when the dangerous functions are used.

1 0

Moving particle checks to python
by Daniel Russel 04 Apr '08

04 Apr '08

The first patch moves the checks that particles have a requested attribute out of the C++ runtime pathway. They are kept in the C++ debug builds and are added to the function calls from python The second adds an offset to Linear. It is not really necessary, but makes printouts of the energy must easier to understand. And shouldn't add significant overhead.

1 0

bye, bye XYZParticle
by Daniel Russel 01 Apr '08

01 Apr '08

Since XYZParticle was pretty much on the way out (and was quite problematic) I cleaned it out. Now the there is a method IMP.test.create_point_particle(model, x,y,z) which does exactly that. In the process also removed some other dead code from IMP.test.

1 0

Inactive particles redux
by Daniel Russel 01 Apr '08

01 Apr '08

Inactive particles are still a mess. For example, most of the optimizers will bomb if there are any inactive particles in the model (which, since we can't delete particles, there will be). The model iterators should skip inactive particles (that is easy enough), but then anything written in python which calls Model.get_particles() will still run in to them. My best idea so far: reference count particles. -When the reference count goes to 1, then they are removed from the Model (since that means nothing other than the model points to them). - Since they have no virtual functions, reference counting can be done. - This way everything is safe and the user can't blow things up by inactivating particles. - Since nothing other than the optimizers should ever really be looking through all the particles in the model, leaving the particles there until the user cleans up all references should be ok. - If you want to delete a particle, you can make sure you do so by making sure that trying to fetch it from the Model fails. We do, perhaps, need to make sure that indexes aren't recycled too quickly.

1 0

Moving runtime checks to python
by Daniel Russel 01 Apr '08

01 Apr '08

Unscientific profiling suggests that my IMP code is spending much of it time in check code, specifically checking that a particle contains a given attribute when fetching or setting its value. This check is not needed in C++ code that is not currently being debugged and it is extremely hard for the compiler to prove they are not needed. So I think the right solution is probably to replace the IMP_check in the C+ + code with an IMP_assert and wrap the methods with python code which checks that the attribute is there and throws an exception if it is not. There are probably a few other places like get_particle where this is also the case, but they don't seem to be bottlenecks at this point. Any thoughts?

1 0

Minor patch to units and constants
by Daniel Russel 01 Apr '08

01 Apr '08

Constants now are all uppercase and some extra printing was removed and one of the sanity checks was made sane.

1 0

Proposal: GravityCenterScoreState
by Ben Webb 01 Apr '08

01 Apr '08

Keren and Frido want to be able to create restraints that act on spherical 'blobs' - which may correspond to protein domains or perhaps to some other defined group of atoms - while at the same time having restraints on the underlying atoms themselves. Thus, the positions of the blobs need to match the positions of the atoms. (In the Modeller or CHARMM worlds, this would be achieved with a gravity center pseudoatom). Thus, a proposal: a GravityCenterScoreState, which would take a list of hierarchy particles and a boolean flag (to turn on/off mass weighting). It would provide a method set_positions() which would set xyz attributes for each hierarchy particle to match the gravity center of the child atoms. (These attributes would be marked as non-optimizable, of course, since they are derived.) It would also have a protected method transform_derivatives(), which would back-transform any forces on the gravity center to the children. (Note that there are several other kinds of pseudo or virtual atom, such as the several Modeller uses for NMR. If there is interest in these we could of course come up with a suitable class hierarchy. For example, one extension would be to turn the hierarchy particle into a sphere, by also populating a radius attribute, e.g. from the radius of gyration of the children. But I think currently nobody uses anything but gravity centers anyway.) This ScoreState would require a change to the API. ScoreState::update (called before the score is evaluated) would be renamed ScoreState::pre_update and a new ScoreState::post_update method would be added (called after the score is evaluated). Gravity centers would simply call set_positions() from pre_update() and transform_derivatives() from post_update(). Existing ScoreStates would provide a do-nothing implementation for post_update(). Comments? 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 2

remove fixed particle optimization
by Daniel Russel 01 Apr '08

01 Apr '08

The non bonded lists no longer assumes non-optimized particles are not being optimized. The singleton restraint doesn't warn about being applied to them either.

1 0

← Newer
1
...
70
71
72
73
74
75
76
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev