IMP-dev September 2010

imp-dev@salilab.org

3 participants
4 discussions

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

optimizing restraints for speed
by Daniel Russel 30 Sep '10

30 Sep '10

prompted by work I did breaking up restraints in domino2 in order to improve filtering and restraint evaluation and work special casing restraints in order to handle spring natively in Bullet and openmm, I thought it could be cool to add functionality to IMP to automatically modify the set of restraints used in order to make them faster. The idea would be to have a static list in the kernel of known optimizations. Restraints, or anything else, could add optimizations to the list, and then optimizers would apply the optimizations before performing its optimization steps (and clean up the changes upon exit from the optimizer). optimizations could include things like: - automatically replacing DistancePairScores which use Harmonics with HarmonicDistancePairScore - replacing BondSingletonScores with HarmonicDistancePairScores when appropopriate (the makeup of the bonds can't change) etc - use the C++-only generic restraints in some common cases These can provide a factor of two reduction in evaluation time in certain cases. Disadvantages: - calling optimize with only one iteration would be kind of slow, but why would you do that - work needs to be done by me :-) This would be different from the restraint/container optimization in Domino2--the name of that should probably change to decomposition or something less generic. So, how much do people want more speed when evaluating lots of simple restraints?

2 1

ClosePairsPairScore
by Daniel Russel 27 Sep '10

27 Sep '10

Does anyone use it? It seems awfully complicated as it is. I would propose changing the implementation to - get rid of the recusive application of the Refiner - not require intermediate balls for efficiency - use the algebra nearest neighbor search (build in ANN or CGAL) to make things actually faster

1 0

rigid fitting into EM density maps in IMP
by Keren Lasker 13 Sep '10

13 Sep '10

Dear IMP dev, In the sake of transparency and collaboration I wanted to give everyone an update on the work we have been doing on em fitting. We will try to send these updates to everyone from time to time so the work being done is fully transparent and clear. The recent efforts can be divided to two main categories: 1. scoring We worked with Daniel and Ben on various code optimization that now allow for even faster rigid body scoring. Specifically, the model simulated map is resampled only once and for the rest of the transformations the resampled map is transformed. We are also now able to apply the same idea to multiple rigid bodies, as we found a way to decompose the CC score into rigid terms, while still maintaining the correct combined score. Examples can be found in the test can examples directories on the em module. 2. optimization We have developed 4 rigid fitting procedures: (i) MC/CG local refinement, (ii) principal component based rigid fitting, (iii) fft based rigid fitting and (iv) anchor points based rigid fitting. (i) and (ii) are fully integrated into IMP, while (iii) and (iv) require external libraries (fftw3 and gamb), and are now in the process of being merged into IMP with Ben's help. Examples can be found in the test can examples directories on the em and multifit modules. Current usages of the new code were quite successful. Charles used it to fit 1000 proteins into more than 5000 maps and all went well. In addition, we tested the new code on a large benchmark of protein assemblies and were able to get accurate fits. As we are in the process of making all publicly available in IMP 1.1 and currently writing a tutorial on the em module in IMP, we will be happy to get specific feedback, comments or ideas for improvements. thanks, Keren.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev September 2010