October 2010 - IMP-dev

tutorials module in IMP?
by Keren Lasker 05 Nov '10

05 Nov '10

hi - We have few sets of tutorial scripts that are currently scattered in various modules within imp and outside of imp. I think it would make sense to have a module named tutorials and then subdirectories for the different tutorials. For example, our recent book chapter on assembly modeling by comparative modeling and em can go there. thoughts? keren.

4 9

radii and read pdbs
by Daniel Russel 01 Nov '10

01 Nov '10

Given that - doing almost anything useful requires adding radii to atoms - we currently have only one way to do that - it generally doesn't matter what radii we use for atoms for most of what we do - one can always overwrite the radii with other values if one wants other values I propose the read_pdb function add radii to the atoms it creates. Comments?

4 11

thoughts on merging IMP.helpers into IMP.restrainer
by Daniel Russel 26 Oct '10

26 Oct '10

Currently, IMP.helpers is only one .h and one .cpp used primarily by restrainer and has now interesting external dependencies. If they are not used much outside of restrainer and there are no plans to add significantly more functionality, I think it might make more sense to move them into the restrainer module. Adapting existing code would be trivial (simply replace IMP.helper by IMP.restrainer), so the cost is small. And reducing the number of modules is always nice.

1 0

Correction: Keren is talking thursday at 3
by Daniel Russel 25 Oct '10

25 Oct '10

Sorry.

1 0

Recently in IMP
by Daniel Russel 25 Oct '10

25 Oct '10

Recent changes: • IMP::atom::Selection was added to allow specification of parts of IMP::atom::Hierarchy using biological sorts of names. A few functions to create restraints from them were added too. • a new example was added in the kernel to show IMP used on a biological system • IMP::display::PymolWriter now supports adding labels to things • IMP::display::PairRestraintGeometry and IMP::display::ConnectivityRestraintGeometry were added to aid in visualizing those restraints. • IMP::bullet was added with an optimizer to use hard body physics to resolve local collisions. • IMP::atom::setup_as_rigid_body() has been deprecated and replaced by IMP::atom::create_rigid_body(). The latter creates the rigid body as a separtate particle so that the molecular hierarchy doesn't have to worry about having its bounding sphere large enough to enclose all the members. • IMP::core::KClosePairsPairScore was added to have count based cutoffs for close pair scoring. • IMP::algebra::get_surface_area_and_volume() was added to compute the two numbers for a set of balls • Two examples were added to the kernel, Nup84 CG and Nup84 RB which illustrate the usage of many aspects of IMP. As a reminder, Keren is discussing the RNAPII example tomorrow at 1.

2 1

next meeting: modeling the RNAPii complex
by Keren Lasker 22 Oct '10

22 Oct '10

based on homology modeling, em and proteomics The meeting will take place on Thursday 3pm.

1 0

Recently in IMP
by Daniel Russel 15 Oct '10

15 Oct '10

- IMP::core::ClosePairsPairScore has been split into IMP::core::ClosePairsPairScore and IMP::core::KClosePairsPairScore as the previous version encompassed two different, easily confused, behaviors. It now is accelerated and takes advantage of rigid bodies. The constructor signature was changed to force you to revisit code that might be affected by the behavior changes. IMP::core::RigidBodyDistancePairScore is now just a wrapper on IMP::core::KClosePairsPairScore. - IMP::atom::Selection was added to facilitate representation independent setup of restraints and manipulation of hierarchies. Check it out. - a new, more involved example, kernel/examples/nup84_cg was added, blatantly ripping off Elina's restrainer nup84 example

1 0

biological names for things
by Daniel Russel 14 Oct '10

14 Oct '10

Since I keep bringing up that it is good to be able to refer to parts of the representation using biological names, I thought I would throw together some code to do that. The goal is to allow one to set up the restraints without ever explicitly referring to particles, just asking for parts of the hierarchy. The advantage of this is that - one can change the representation pretty much arbitrarily without messing with the restraints code - the restraints code is much easier to read - you don't have to worry about whether the representation happens to contain a Fragment referring to the piece of the molecule you are interested in (and hence avoid the problem of overlapping, but not nested, fragments). For the implementation, there is a class IMP.atom.Named which describes a part of one or more molecules. You create a name with doing various things like nm=IMP.atom.Named(hierarchy=h, molecule="my molecule", residue=10) (assuming there is more than one molecule in h) and then can get the one or more particles referenced by it with nmps=nm.get_particles() eg, if h is an all atom mode, nm.get_particles() will return the atoms in the residue, if it is a coarse grained model, it will return the particle containing the residue. The names can be used to create a distance restraint with IMP.atom.create_harmonic_distance_restraint(IMP.atom.Named(hierarchy=all, molecule="proteina", residue=10), IMP.atom.Named(hierarchy=all, molecule="proteinb", residues=(1,10), 10, 1) which will return a restrain limiting the distance between the 10th residue of proteina and the first 10 residues of proteinb to 10A with a spring constant of 1. The restraint is a SphereDistanceRestraint if each of the two Named refer to just one particle and a ConnectivityRestraint using a ClosePairsPairScore if they refer to more than one (the ClosePairsPairScore internally takes advantage of rigid bodies if the hierarchies are rigid bodies). I haven't wrapped any other restraint types yet. With EM, for example, one might as well just pass nm0.get_particles()+nm1.get_particles() to restrain two molecules with a map. It is just something I threw together on the train, so I wouldn't trust the code much yet (and the name "Named" isn't great, but I want it to be short). The Named objects can be created with any combination of - one or more names of molecules - a single residue index or list of residue indexes (or ranges)-- later we can add tags for the C- and N- terminus - one or more atom types - one or more residue types - one or more chain identifiers - one or more domain names - a target radius (so that you can refer to intermediate levels of the hierarchy) eg Named(hierarchy=h, chains=['a', 'b'], target_radius=10) which gets as close to 10A representation of the two chains as one can. Name(hierarchy=h, atom_types=[CA]) which gets all C alphas This way you can write functions to set up restraints without any direct reference to particles. Thoughts? Does it seem useful? I quite like using such code when setting things up.

1 1

Recently in IMP
by Daniel Russel 11 Oct '10

11 Oct '10

Some recent changes that might be of interest - a wrapper for the Bullet physics simulation system was added to allow it to be used to optimize models. I recommend everyone take a look at it as a possible a replacement for conjugate gradients in certain contexts. It is not general purpose (it works best when excluded volume and harmonics dominate), but it is very stable and can get to a decent configuration from quite bad ones. We can add support for rigid bodies if desired, but currently only XYZR particles are optimized. An example is provided. - various bits of IMP should be faster (at least with fast builds), including non-bonded lists. I added a section on speeding things up in the introduction, http://salilab.org/imp/nightly/doc/html/introduction.html. - modules can be selectively ignored when running scons by using "disabledmodules=helper:restrainer:domino" (or some other list of modules) on the command line or the config.py. This can make scons run much faster when you are working on modifying one module since it won't configure the listed modules. Be aware that modules that require the disabled modules will also be disabled (and so ignored). Also note that you can skip the scons dependency checks by doing, eg fftw3="yes" and fftw3libs="fftw3". or create a fully specified config file configuration file (by doing "scons config.py"). As a note, if you are not doing out of source builds, you probably should be as it makes switching between fast and debug builds painless. See instructions at <http://salilab.org/imp/nightly/doc/html/installation.html>. Likewise, everyone should probably have their own module (see "managing your own module" on <http://salilab.org/imp/nightly/doc/html/devguide.html>), checked in to your own svn repository so you have an easy way to fiddle with things.

2 3

Proposed modification of how code accepts rigid bodies
by Daniel Russel 08 Oct '10

08 Oct '10

Currently, code that handles rigid bodies does it by taking a list consisting of both RigidBody particles and non-rigid body XYZR particles along with a Refiner to turn the rigid bodies into XYZR particles. This has several disadvantages: - it seems to confuse the hell out of everyone - it forces all rigid bodies to use the same refiner - it means that you have to pass a completely different set of particles if some of them happen to be rigid than if none are rigid I propose a new standard type of interface, namely, simply taking all the XYZR particles of interest, whether or not they happen to be part of a rigid body. That is, if you have some rigid proteins and some non-rigid proteins and are representing everything with all atoms, you simply pass all the atoms. I think this has the following advantages: - the user no longer has to worry about whether things are rigid bodies or not, certain code just runs faster when they are - the user doesn't have to change the set of particles passed when moving to rigid bodies It has the following disadvantages - code that takes advantage of rigid bodies is more complicated as it has to group the particles into rigid bodies: this is only a few lines of code and can be factored out, so it doesn't seem too bad - code that takes advantage of rigid body has to do more work. I don't think the extra work will be that large in practice, but am not yet sure Typical things affected would be - ExcludedVolumeRestraint - RigidClosePairFinder - perhaps FitRestraint Thoughts?

2 2