- IMP-dev - salilab.org

Making IMP faster
by Daniel Russel 24 Feb '09

24 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 21 Feb '09

21 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 17 Feb '09

17 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

Moving algebra to doubles
by Daniel Russel 13 Feb '09

13 Feb '09

As was mentioned before, it is probably a good idea to move all the storage and computations in the algebra module to use "doubles" in order to improve numerical robustness. IMP::Float would stay as "float" for now. Probably the cleanest way to do this is to replace all "Float" with "double" in the existing code. This appears to work without problems. If no one objects, I'll submit the patch soon.

2 1

Minor changes
by Daniel Russel 13 Feb '09

13 Feb '09

the version info headers now don't have the redundant module name prefix: IMP/core/internal/core_version_info.h -> IMP/core/internal/version_info.h Same for the class defined inside. There is now one big swig macro to wrap the constructor (IMP_OWN_CONSTRUCTOR) instead of different macros depending on the number of arguments. Everything in SVN has been fixed.

1 0