IMP-dev July 2012

imp-dev@salilab.org

7 participants
7 discussions

Policy for versions of IMP dependencies
by Daniel Russel 31 Jul '12

31 Jul '12

As Ben just had to patch something to handle a very old version of boost, I think it might be worth thinking a bit about how our requirements for versions of third party libraries change over time. When IMP started, we decided we needed to support versions of dependencies (boost, swig, scons, python, gcc etc) that are part of the mainstream platforms, eg things like - latest RHEL/CentOS - latest ubuntu - latest XCode/macports - the version of visual studio on Ben's test machine :-) (also homebrew and fedora, but they are, in general, strictly newer than things on the list) So far we have more or less stuck with the versions of the dependencies, rather than the policy (eg, I don't think any of those use boost 1.33 but we still require that we support it). It seems to me it might make sense to keep these as the live requirements, that is, drop old versions as they become older than the versions in the list above. I think the main immediate effect would be to update to boost 1.40, and gcc 4.4, which would remove a bunch of work around and open things up for a number of boost libraries (foreach for example) and CXX11 features (perhaps even auto and range based for loops :-) although we would have to check with visual studio and the apple compilers).

7 19

RMF backward compatibility
by Daniel Russel 27 Jul '12

27 Jul '12

I removed some code from the RMF library that provided backward compatibility with certain rather old files (1 year+ I think). If you run into any files that don't open after you update IMP and they matter, I can put the code back (I rearranged some functions and would have had to update the code). Alternatively, if you know you have some old files, you can do rmf_slice old.rmf new.rmf -f -1 which will update the files into new.rmf (the -f -1 just means move every frame).

1 0

IMP documentation & tutorials by the people
by Barak Raveh 18 Jul '12

18 Jul '12

Hey guys, Here is a very tempting suggestion, which might benefit all of us in the long run, but will require some group effort :) As we all know, though lots of efforts have been made to document IMP, getting started on IMP development or usage is (quite naturally) still somewhat far from obvious (missing or outdated documentation or examples, no tutorials etc.). So - the idea is that if we team up, we can improve the documentation and write tutorials in relatively small effort, benefiting new users and developers, and surely also old ones. We can then have peer-reviewing of the resulting documentation (e.g., one team checking the documentation / tutorials written by another team). Here are some initial ideas Daniel and I had in mind, and feel free to add suggestions: * A team will make sure the Getting Started and Developer Guide are up to date, make them even friendlier and extend them further * Other teams will validate existing example codes, add missing example codes, and most important, write friendly tutorials on how to accomplish common IMP tasks (both development, e.g., "how to write new code for Monte-Carlo simulation with restraints", and usage e.g. "how to dock from EM") * Perhaps one team can also go over some key classes and improve their code documentation, especially in the core / kernel / base / atom modules. Ok, Who's in? :) We will try to keep the task relatively smalls, so that they can be done in 1-2 working days. Cheers, Barak

3 3

Re: [IMP-dev] Optimizer
by Daniel Russel 16 Jul '12

16 Jul '12

A couple of comments: - There is already a Quasi-Newton implementation in GSL (using the GSL library). - the simplest optimizer we have currently is probably core::SteepestDescent, so that might be a good one to look at for code to read to get started. core::ConjugateGradients is a bit better developed and structurally simple although the actual optimization function in it is awfully complicated to follow. We don't have an example optimizer at this point. - the IMP_OPTIMIZER() macro simply defines some basic functions and declares do_optimize and do_show (which you then need to implement in your .cpp file). For some reason it doesn't appear in the nightly docs. Not sure why as things look ok. You have to read modules/kernel/include/optimizer_macros.h, sorry. I added imp-dev as this topic seems of general interest. On Mon, Jul 16, 2012 at 9:56 AM, Pia Unverdorben <unverdor(a)biochem.mpg.de>wrote: > Dear Ben and Daniel, > > together with an intern I would like to build a quasi newton optimizer in > IMP. Do you have an example or "recipe" on how to setup such an optimizer > and how to use the IMP_OPTIMIZER() macro? > Thanks a lot! > > Cheers, > Pia > >

2 1

rmf file size
by Riccardo Pellarin 06 Jul '12

06 Jul '12

Hi all. I'm using the rmf file support to write coordinates of my optimization run. I set up the rmf file in this way rh = RMF.create_rmf_file("traj.rmf") IMP.rmf.add_hierarchy(rh, self.prot) and then at each step "i" I save the coordinates in the file for i in range(10000): mc.optimize(100) IMP.rmf.save_frame(rh,i) Now, the resulting rmf file for my system has a size of about 100 KB per frame, which is only slightly lower than the 120 KB per frame of an appended pdb file. (My optimization run saves 100000 frames, which makes about 10 GB for the rmf). How is it possible that a binary file is that bulky? For comparison, a dcd trajectory frame only occupies 18 KB, for the same system. Am I doing something wrong? cheers Riccardo

2 1

write the granularity of the logs
by Javier Velazquez 05 Jul '12

05 Jul '12

I have a simple proposal. write the granularity ad the beginning of each log message. Something like LOG:TERSE blah blah Then a couple of "greps" would make going through all the output less painful, wouldn't it?

6 8

Re: [IMP-dev] Is it possible to write decorators in python?
by Daniel Russel 03 Jul '12

03 Jul '12

Added imp-dev. First, a general comment. As you point out, swig doesn't wrap protected methods, which doesn't interact well with various C++ idioms that use them. Better supporting python would require either making those methods public or doing some trickiness where they are public to swig and the swig wrappers (and visual studio since it makes the protection part of the method signature), but protected when seen by the C++ side of IMP and doxygen. It is probably worth instituting one of these as standard practice in IMP. For example by adding an IMP_PROTECTED macro that resolves to the correct one of public/protected depending on the context. As for Decorator, the public constructor you see is, somewhat confusingly just there to illustrate what an actual decorator should look like (it only appears in doxygen). It probably makes for cleaner docs to simply link to the ExampleDecorator. I'll fix that presently. On Jun 28, 2012, at 4:23 PM, Javier Velazquez wrote: > Daniel, > > Running a program with the decorator below stubbornly says: > def __init__(self, *args, **kwargs): raise AttributeError("No constructor defined") > > According to SWIG's manual no constructor is wrapped if it is protected. It is indeed protected in Decorator.h, but you define a public constructor too. As a result of not accessing the public decorator, I can't access the member function get_particle(). There is a way around this problem using a self.particle member, but looks ugly, and I don't know if it is entirely correct. Is there a correct way to do it? > > > Thanks > > > class Price(IMP.Decorator): > price_key = IMP.IntKey("price") > > def __init__(self, p): > if not self.particle_is_instance(p): > self.setup_particle(p) > IMP.Decorator.__init__(self,p) > > def setup_particle(self, p): > p.add_attribute(self.price_key, 0) > return Price(p) > > def get_price(self): > return self.get_particle().get_value(self.price_key) > > def set_price(self, x): > self.get_particle().set_value(self.price_key, int(x)) > > def particle_is_instance(self, p): > return p.has_attribute(self.price_key)

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev July 2012