IMP-dev February 2009

imp-dev@salilab.org

8 participants
27 discussions

This week in IMP
by Daniel Russel 27 Feb '09

27 Feb '09

As per Keren's suggestion, I'll start sending out a summary email of IMP-related changes. Once Ben updates the web page, the change list can go on web page and so be frequently updated in addition to the email. - Sphere3D and Cylinder3D have been added to algebra. So we now have standard ways of specifying rotations, transformations, spheres, and cylinders. If your function takes a description of one of those, please have it take an instance of the appropriate class instead. - a new module, 'display' has been added to support exporting geometry to external programs. It currently supports spheres, cylinders, XYZRDecorator particles, BondDecorators, axis aligned boxes, and triangles, and supports output to Bild, CMM, VRML and CGO (a pymol format). - functions to generate a cover of the surface of a cylinder and sphere have been added in addition to existing functions to randomly sample in and on spheres and axis aligned boxes. - the build script has been changed so that you can add a module locally (by putting it in modules) and you don't have to change modules/SConscript (use the localmodules=True flag) - particle indexes are still scheduled to disappear (and get_particle(unsigned int) is linear time) so stop using them - rigid body support has been added both via snapping the members to preserve rigidity and via direct optimization of the rigid body orientation and translation. The code has only been tested in a limited manner. - a check has been added to IMP for incorrectly defined functions. If you get a linker error involving link_0.cpp and link_1.cpp and duplicate symbols, it probably means you defined a function in a header and forgot to make it inline. - transformations are now composable and probably a few other things I have forgotten. Before you implement something, check if it is already there by using the search in the manual and, if not, by emailing imp-dev. Emailing such questions to the list lets people know what you are using and refreshes people's picture of what is in IMP. In addition, many of us have useful code around that isn't in IMP, but easily could be. It is good practice to keep a second (or 10th) copy of IMP around that you never change directly and simply keep in sync with the current svn. When you commit changes to SVN, update your svn copy and run the tests there to check that you haven't forgotten to commit anything important (such as an SConscript or a related file in another directory).

1 0

using algebra from em module
by Keren Lasker 27 Feb '09

27 Feb '09

hi, including algebra classes in em module does not compile - is there some change needed in the build system for that ? thanks, keren.

2 1

Making IMP faster
by Daniel Russel 25 Feb '09

25 Feb '09

Since it has come up a few times recently, if you want IMP to run faster, try 1) call IMP.set_checks_level(IMP.NONE) before you do your optimization 2) rebuild with "build=fast" These disable all or most checks (and the second enables more optimization), so please make sure your code works with checks and does not print any warnings first.

1 0

display module
by Daniel Russel 22 Feb '09

22 Feb '09

Since it was getting to be very messy trying to change one of the LogOptimizerStates every time I wanted different output, I wrote a new module for doing (graphical) output from IMP, called IMP.display. It provides abstractions for turning particles into geometry and writers to write the resulting abstractions as CMM, VRML or Bild files. Currently there are classes to generate geometry from XYZR particles and from bond particles. There is also a single LogOptimizerState class which subsumes both VRMLLogOptimizerState and CMMLogOptimizer state (which are now marked as deprecated). Anyway, take a look at things and see what you think. I have added an example in fragments.

1 0

Naming and *Modifiers
by Daniel Russel 20 Feb '09

20 Feb '09

I would suggest that we remove the SingletonModifier and PairModifier suffixes from the modifiers since it makes the names ridicuously long and the rest of the name is descriptive enough (eg DerivatiesFromRefined or AccumulateRigidBodyDerivatives). Any objections? This would change the name of a few existing classes and quite a few new ones.

1 0

Ways of using IMP
by Daniel Russel 18 Feb '09

18 Feb '09

I think we need to put some thought towards what ways of using IMP we want to support. As I see it, there are two usage models to support: 1) The user installs IMP in some standard location and uses it like any other library. This is supported by the current scripts, if not heavily tested (I don't think anyone currently uses it this way). Such usage is great if you only have one version of IMP that you use, are not frequently changing IMP, and only use python or use your own build system. 2) The user adds a module to IMP (but does not check it in to IMP svn) and uses the IMP build system and imppy.sh to run things. Such usage has the advantage that you don't have to mess with the build system (so novices don't have to be shown much), you don't have to set your PYTHONPATH, making changes to IMP is easy an quick, it is easy to keep IMP up to the current svn head, and should you decide to contribute your code back to IMP, not much has to be done. Currently this model is a bit messy though since you have to modify modules/SConscript (and avoid accidentally checking in the modified file), and, if you want to use svn nicely, modify your local svn state for modules (to add a your module as an svn:extern). This process could be made nicer in a couple of ways: - move all the Scons code related to each module into the module directory - add an external_modules directory which has a glob-based SConscript (which doesn't need changing), but is otherwise treated similarly to the modules directory and which can't easily be changed (other than the SConscript file). Thoughts? Other usage models? Ways of making these easier? I think Keren uses IMP by calling imppy.sh from an external project. I would like to discourage this model as it doesn't give much benefit over installing IMP, makes it harder to control what version of IMP you use (since you can't easily check out IMP, and then not use it), and makes the external library very dependent on details of the (necessarily) messy imppy.sh. For example, imp using modeller through the modpy.sh script has caused horrible and tricky to debug problems for each of use at various points.

4 7

Final score and optimizer questions
by Davide Baú 18 Feb '09

18 Feb '09

Hi, I have a couple of question regarding how to visualize detailed information about the final score of a model and the Metropolis criteria: 1. Is there a way to show/determine each particle contribution to the final score (i.e. is it possible to determine the amount of restraints fulfilled by each particle of the model)? 2. About the temperature in the Monte Carlo optimizer. The get_temperature() method returns the temperature set for the Metropolis criteria. Is there a way to show how the temperature decreases during the optimization protocol? Thanks in advance! Davide ____________ *Davide Baù* Structural Genomics Unit Bioinformatics & Genomics Department, Prince Felipe Research Center Avda. Autopista del Saler, 16 , 46012 Valencia, Spain Tel: +34 96 328 96 80 (ext. 1021) Fax: +34 96 328 97 01 Email: *dbau(a)cipf.es* Web: *http://sgu.bioinfo.cipf.es/dbau*

2 1

Attribute scaling
by Daniel Russel 18 Feb '09

18 Feb '09

It came up in the context of rigid bodies that certain optimizers (namely CG) like to have all their parameters vary over a similar scale. As a result, it can be important to rescale non-xyz attributes. One way of doing this would be to add a method to Model: FloatPair get_range(FloatKey) which returns the current range of values for a particular FloatKey. Then CG could use that to rescale all its values internally. If it is useful to be able to override the range, we could also add set_range which allows you to set the expected range (perhaps even allowed range) for a given attribute type. Both of these would be relatively easy to implement on the Model side. The CG code is a bit hairy, so tweaking that could take more work (and is probably best done by adding another set of methods to access the values in the Optimizer base class).

3 4

what is now "AllNonbondedListScoreState" ?
by Keren Lasker 18 Feb '09

18 Feb '09

2 1

modeller restraints from imp
by Keren Lasker 17 Feb '09

17 Feb '09

hi, Can one call modeller restraints from imp and use it in the optimization ? thanks, Keren.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev February 2009