IMP-dev June 2009

imp-dev@salilab.org

6 participants
10 discussions

Next IMP developers meeting
by Daniel Russel 29 Jun '09

29 Jun '09

Can we have it Wednesday before group meeting instead? I have a workshop all Tuesday. Also, the topic will most likely be an introduction to STL and Boost and other C++ libraries that are good to know about.

4 7

Units in IMP
by Daniel Russel 27 Jun '09

27 Jun '09

I have been making extensive use of some C++ classes I wrote to do compile time unit analysis in IMP. I find them very useful and wouldn t want to have to write code without them and as a result thought I would ask if others are interested. They enable things like - automatically converting between different length measures (say angstroms and nanometers) so you don't have to worry which number is which - check that unit types match, so can can't assign an energy value to a force or daltons to kilograms - convert between SI units and the energy units used in IMP etc. You use them by writing things like Nanometer side(10); CubicAngstrom volume= side*side*side; Nanosecond time_step(10); simulation_parameters.set_maximum_time_step(time_step); // it otherwise would want femtoseconds As a said, I quite like using them and would like to make them generally available. There are a couple of holdups: - since it is a compile time library, it doesn't really translate to python, so we would need to continue to provide separate units and unit free interfaces for things (for example SimulationParameters has set_maximum_time_step and set_maximum_time_step_in_femtosecond, the latter just takes a double - Boost, has added its own units library (as of 1.36). It is based on the same principles as mine (they both grew out of a Boost.MPL example) but there are various differences so converting to the boost one would take a bit of work and we would need to provide some of our own code on top of the boost library. My thought had been to wait until IMP required a new enough boost and switch to that, but it is taking a while. Are people interested? The code is pretty stable, but could use a bit of documentation and cleanup if others are to use it.

2 2

Last week in IMP
by Daniel Russel 26 Jun '09

26 Jun '09

Nothing too much changed: * box distrubutions (IMP::algebra::random_vector_on_box(), IMP::algebra::random_vector_in_box()) take bounding boxes * IMP::em::DensityMap are now IMP::Object objects. Some current allocations on the stack may need to be changed. * IMP::em::DensityMap::Read() is now deprecated (as is Write). Use the more conventional IMP::em::read_map() and IMP::em::write_map() instead. Remember, any time an object accepts and stores a pointer to another object, the passed object must be reference counted. Otherwise it is very difficult for users to get memory management correct. To make an object reference counted inherit from RefCounted or Object and used IMP::Pointer instead of a raw pointer to store.

3 2

ScoreState vs Constraints
by Daniel Russel 16 Jun '09

16 Jun '09

The name ScoreState seems to confuse a few people. As Hao pointed out, they are actually constraints. Any reasons not to rename them to that? It would be a relatively easy shell script (and user code could be updated via sed).

2 1

Decorators vs particles
by Daniel Russel 16 Jun '09

16 Jun '09

The issue of functions taking Decorator objects, or Decorators objects as arguments vs Particle* and Particles keeps coming up. Mostly we currently are going for Decorator objects and Particles the moment which is reasonably practical, but odd. Taking decorators makes the docs better (since it is clear what is expected from the particles), but then you have to convert things back and forth everywhere. One solution for this on the C++ side would be to: - write all methods to take Decorator objects and Decorators. This makes the docs nice and doesn't require duplicating methods - allow implicit conversions from Particle* to Decorator objects (I currently disallowed it) - allow implicit conversions from Particles to Decorators (by making Decorators be something other than std::vector, which is easy enough) Ben, can such be made to work on the python side too via typemaps? I had looked at doing implicit conversions at some point and couldn't quite figure out how to make it work.

2 2

This week in IMP
by Daniel Russel 13 Jun '09

13 Jun '09

- new methods IMP::atom::add_radii() and IMP::atom::add_bonds(); - Hierarchys to IMP::atom::Hierarchies - IMP::Particles has been changed to a new type. It no longer plays quite so well with python lists (you can't create a part one from an arbitrary python list). - The contains for multiple decorators have been revised to make them more useful. See IMP::Decorators. You can now implicitly convert, for example, a IMP::core::XYZs to an IMP::Particles (as well as use IMP::Decorators::get_particles()). All methods that take a collection of particles with a certain type now instead take a IMP::Decorators. - A method that has expectations about the particles it takes should take decorators rather than particles. That is, anything which expects IMP::core::XYZ particles, should take an IMP::core::XYZs instead of IMP::Particles. - IMP_LIST() now takes an extra argument (the name of the plural container) - In C++ IMP::Decorator objects are implicitly convertible to IMP::Particle* objects. Unfortunately, making this work in Python is problematic. - More methods take and return decorators rather than IMP::Particles. This means it is clearer what their expectations are and what they produce.

1 0

Failure rate of restraints
by Daniel Russel 08 Jun '09

08 Jun '09

With Keren, we ran into problem caused the fact that em restraints go to 1 as they are increasingly violated while hard sphere restraints go to larger numbers (and are dependent on the number of particles). The result was that the em restraint would get more or less ignored by the optimizer unless a large scaling factor was added to EM. This experience raises an important question: Do we want a convention about how restraint scores behave as they are increasingly violated? A convention could be something like: - all satisfiable restraints (ones whose optimal is at 0) should have scores that go as x^2 (or just as x) per atom where x is the displacement is angstroms from a satisfying conformation. - a restraint score can stop increasing at a value where there is no longer any signal. Obviously, one could only very roughly approximate this in practice, but a rough approximation might be good enough to get many of the benifits Advantages: - You have a natural starting point for weight values between the various restraints. Variations from this are directly upweighting or downweighting data relative to them having equal importance. - The relative importance of restraints does not depend on how far from optimal you are - The relative importance of restraints does not depend on how many particles they are restraining - The importance of various terms won't depend on the scale of the representation Feasibility: - core restraints such as Diameter and stuff would require using a per-particle scaling factor (to incorporate the number of atoms). Excluded volume is approximately correct too given such a scaling (at least if the model isn't too messed up) - EM would require adding a term to penalize things for escaping far from the map as well as some experiments on how things break down under random displacements of various amounts (and rescaling of cross correlation accordingly) and scaling by the number of particles. Such could easily be added as a wrapper around a CC based restraint. And understanding of those issues seems important anyway. - others?

4 14

has anyone written a heavy atom selector in IMP.atom ?
by Keren Lasker 08 Jun '09

08 Jun '09

2 1

mean orientation
by Keren Lasker 07 Jun '09

07 Jun '09

hi, did anyone figure out how to find the mean orientation from a set of rotations ? It is not a simple mean operator on quaternions as q and - q represent the same orientation. Keren.

2 3

"smart" orientation grid search
by Keren Lasker 02 Jun '09

02 Jun '09

hi all, Has anyone implemented a function that generates a set of grid search orientations ? something like: IMP::algebra::Rotation3D rotation_grid_search(IMP::Float distance); We have sphere based and cylinder based rotation sampling, but it seems that there are better ways (quaternions based) that maintain a fixed "distance" between all pairs of orientations. thanks, Keren.

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev June 2009