September 2009 - IMP-dev

IMP.FloatKey('x')
by Friedrich Foerster 28 Sep '09

28 Sep '09

hi all, for some reason, my just-compiled version of IMP (stable branch) miserably fails. e.g., one of the unit tests gives the below problem. any clues what is wrong with my setup? thanks frido sendling 368% pimp /fs/home/foerster/salisoft/imp/branches/stable/modules/atom/test/test_md_optimizer.py /fs/sun15/lv01/pool/pool-foerster/frido/projects/assembler/ Traceback (most recent call last): File "/fs/home/foerster/salisoft/imp/branches/stable/modules/atom/test/test_md_optimizer.py", line 7, in <module> xkey = IMP.FloatKey('x') File "/fs/sandy02/lv08/home/b_baumei/foerster/salisoft/imp/branches/stable/build/lib/IMP/__init__.py", line 438, in __init__ this = _IMP.new_FloatKey(*args) NotImplementedError: Wrong number of arguments for overloaded function 'new_FloatKey'. Possible C/C++ prototypes are: IMP::FloatKey() IMP::FloatKey(unsigned int) IMP::FloatKey(std::string) -- Dr. Friedrich Foerster Max-Planck Institut fuer Biochemie Am Klopferspitz 18 D-82152 Martinsried Tel: +49 89 8578 2651 Fax: +49 89 8578 2641 foerster(a)biochem.mpg.de www.tomotronic.org

1 1

Re: [IMP-dev] OpenMM
by Daniel Russel 25 Sep '09

25 Sep '09

Cool. It shouldn't be too hard to use it as an MD backend for IMP (with supported for whatever restraints can be easily mapped onto their standard terms). On Sep 24, 2009, at 4:05 PM, Andrej Sali wrote: > John: > > It was good to see you too - you never change - always smiling! > > Thanks for this pointer - I cc-ed the whole lab so everybody can > check it out and see if it is helpful for their project. It does > look as if at least our IMP (and MODELLER) developers should take a > very good look. > > Many thanks again, > > Andrej > > Begin forwarded message: > >> From: John Chodera <jchodera(a)gmail.com> >> Date: September 24, 2009 1:27:39 PM PDT >> To: Andrej Sali <sali(a)salilab.org> >> Subject: OpenMM >> >> Hi Andrej, >> >> It was good to run into you again today! It's been far too long >> since >> I've been back to visit folks at UCSF, I think! >> >> I wanted to send more information on the OpenMM toolkit that I had >> mentioned earlier. Vijay Pande (among others) at Stanford is helping >> guide the team that is developing it. The project itself is LGPL, >> and >> can be obtained from the SimTK site here: >> >> http://simtk.org/home/openmm >> >> The toolkit contains a simplified API that makes it very easy to plug >> in the molecular mechanics engine, as well as a number of >> implementations of this API for either CPUs or NVIDIA GPUs (with an >> OpenCL implementation coming soon). The current NVIDIA GPU >> implementation is almost embarrassingly fast: Using a modern GB/SA >> solvent model with no cutoffs, you can crank out simulations 500 - >> 1000 times faster than on single CPU cores. They've also recently put >> in explicit solvent simulation capability with PME, though it's not >> quite as fast. The size of the system you can simulate is limited >> only by the amount of graphics card memory you have, but even >> standard >> gaming cards like the NVIDIA GeForce GTX 285 have 1 GB and can fit >> probably thousands of residues. >> >> The toolkit is in C++, but there is also a set of Python bindings >> (wrapped via SWIG) available here: >> >> https://simtk.org/home/pyopenmm >> >> They're still working toward a 1.0 release, so some of the features >> that will be most useful for reimplementing MODELLER restraints >> aren't >> in yet, but will be in there soon. The drawback is that, to get the >> enormous speedup, all force calculations must be done on the GPU, >> which typically require special coding for special force terms. They >> currently have standard harmonic bond and angle terms, periodic >> torsion terms, Lennard-Jones and Coulomb terms, a couple of GB >> models, >> and a number of integrators and thermostats. What is most exciting >> is >> their 'CustomNonbondedForce', where you simply specify a *string* >> that >> is a Mathematica-like algebraic expression for your interatomic >> energy >> term, as well as algebraic expressions for parameter mixing rules, >> and >> it will automatically differentiate it and figure out how to compute >> the forces on the GPU for you! A similar 'CustomBondedForce' will be >> added soon that will allow easy implementation of all kinds of >> MODELLER restraints. >> >> I've used OpenMM recently to implement a new code for running free >> energy calculations [http://simtk.org/home/yank] and I've been very >> impressed with how well it works. Feel free to pass my contact info >> on to anyone who ends up playing with it in your lab and might have >> questions. >> >> All the best, >> >> John >> >> -- >> John D. Chodera >> QB3-Berkeley Fellow, University of California, Berkeley >> email: jchodera(a)gmail.com >> mobile: 415.867.7384 >> url: http://www.choderalab.org > <friedrichs-openmm.pdf> > -- > Andrej Sali, Ph.D. > Professor, Department of Bioengineering and Therapeutic Sciences > Director, California Institute for Quantitative Biosciences at UCSF > Department of Pharmaceutical Chemistry > University of California at San Francisco > UCSF MC 2552 > Byers Hall Room 503B > 1700 4th Street > San Francisco, CA 94158-2330, USA > Tel +1 (415) 514-4227; Fax +1 (415) 514-4231 > Assistant, Ms. Hilary Mahon, Tel +1 (415)514-4228; Lab +1 (415) > 514-4233, 4258 > Email sali(a)salilab.org; Web http://salilab.org > > > > > > >

1 0

This week in IMP
by Daniel Russel 25 Sep '09

25 Sep '09

- all .i files have been renamed to start with IMP_ to help make dependency tracking easier. - static builds (builds with static=True) build both the static and dynamic libraries and just static executables. This means you should be able to run tests and stuff from static builds. - the \c profile build target has been removed as \c static=True does the important bit of what is needed. Just add -pg to linkflags and cxxflags if you want to do use gprof. - Restraints should now implement IMP::Restraint::unprotected_evaluate() instead of IMP::Restraint::evaluate(). The latter can now be called outside of IMP::Model::evaluate() and will return the right answer always. - \c bin/imppy.sh no longer works, as was previously warned. Use \c tools/imppy.sh instead. The bin directory will go away eventually, for now the script just tells you to use the tools version.

1 0

connectivity restraints
by Friedrich Foerster 25 Sep '09

25 Sep '09

hi all, i noticed that the connectivity restraint must have changed at some point: i want to impose a restraint on two proteins, each consisting of several particles. thus, i am interested in restraining the closest pair between the two proteins. whereas the following code did what i need previously it now calculates all against all distances (including intra-protein distances) - which is not what i want. i'd be grateful if anyone could tell me how i need to change my pseudo code: prot1 = [part1,part2,part3] prot2 = [part4,part5,part6] ufu = IMP.core.TruncatedHarmonicUpperBound( span, k, stddev, 2.) pairsc = IMP.core.SphereDistancePairScore(ufu, IRAD_KEY) connrest = IMP.core.ConnectivityRestraint(pairsc) for pps in [prot1,prot2]: connrest.add_particles(pps) to be explicit: the code now restrains distances in prot1 and prot2, which is what i do not want. i only want the inter-protein distances to be considered... thanks frido -- Dr. Friedrich Foerster Max-Planck Institut fuer Biochemie Am Klopferspitz 18 D-82152 Martinsried Tel: +49 89 8578 2651 Fax: +49 89 8578 2641 foerster(a)biochem.mpg.de www.tomotronic.org

4 18

Minor changes to Restraint::evaluate, safe_evaluate
by Daniel Russel 23 Sep '09

23 Sep '09

Restraint::evaluate() now always should return the correct answer (before it could return garbage if not called from Model::evaluate()). Internally, restraints now have a function Restraint::unprotected_evaluate() which does the actual evaluation (and is what you implement when you implement a restraint). Restraint::evaluate() makes sure the model's score states are updated before calling Restriant::unprotected_evaluate().

1 0

force set_transformation in rigid bodies
by Keren Lasker 23 Sep '09

23 Sep '09

hey Daniel, So changing a transformation of a rigid body is done using the function set_transformation(), but it seems that the change actually happens only after model.evaluate() ( I am guessing after states update ?) is there a way to force the changing on the transformation prior to model.evaluate() ? thank you, Keren.

2 6

atomic analysis in IMP
by Keren Lasker 22 Sep '09

22 Sep '09

question to those how are developing the atomic based code in IMP: do we already have code for determining whether a specific residue is buried or exposed ? thanks, Keren.

3 3

logging
by Keren Lasker 22 Sep '09

22 Sep '09

hello, to my understanding there is a way to set log level of entire IMP or specific instances of classes. If there a way to do something like: IMP.core.set_log_level() ? thanks, Keren/

2 1

weight of a single restraint
by Keren Lasker 21 Sep '09

21 Sep '09

hello, Currently, there is no way to set the weight of a single restraint (only for RestraintSet). Is there any objection to add get/set weight for the Restraint class ? thanks, Keren.

3 4

Terminal oxigens in PDBs are not recognized
by Javier Ángel Velázquez Muriel 15 Sep '09

15 Sep '09

Hi all Dealing with a PDB file that has terminal oxigens OXT, they are not recognized properly and I obtain these warnings: WARNING Atom not found "OXT" residue "ARG" WARNING Radius not found for type "" I guess that is something trivial to consider OXTs as oxigens and assign them the radius of an O. Javi

2 1