IMP-dev April 2008

imp-dev@salilab.org

5 participants
18 discussions

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev April 2008