- IMP-dev - salilab.org

Linear algebra
by Daniel Russel 23 Jan '09

23 Jan '09

I'd like to compute a SVD in IMP, so we need to revisit the question of linear algebra packages. The two main options as I see it are: 1) using some big blas implementation through boost.ublas's bindings. The advantages are that operations will then be really fast. The disadvantages are that is is a bit complicated and introduces an (easy, since basically all systems have some blas library installed) external dependency. 2) use TNT. The advantages are that is is header only and has a nice license so we can hide it away internally. On the flip side, we can't count on it being installed so we have to hide it away internally, and it isn't the best implementation of things. It is also a bit limited (but SVD can solve all problems :-). Unless there are counter proposals, I'll stick a copy of TNT in somewhere.

4 14

memory leakage in IMP
by Friedrich Foerster 23 Jan '09

23 Jan '09

hi all, somehow i keep on stealing my computer memory when running imp from python. either my awkward programming style or a bug in imp/swig steals the memory from my system. attached is an example illustrating the problem. if you monitor the memory usage, you'll see the consumed memory gradually increasing - although the same variable is used throughout the loop. thus, apparently new memory is constantly allocated and i have no clue what happened to the old one. needless to say the code could eventually kills every system given the loop is large enough. any help on the whereabouts of my memory would be greatly appreciated... tx frido

3 4

"python interface" platform
by Daniel Russel 23 Jan '09

23 Jan '09

In the nightly build, there is a platform called "Python interface". What is it?

2 1

New IMP permissions and branches
by Ben Webb 23 Jan '09

23 Jan '09

Further to last Friday's meeting, I have updated the permissions on the IMP Subversion repository, and created some new branches, as detailed below. Note: the IMP SVN trunk should still be treated as "stable". Code checked in should compile and pass its test cases, as is currently the case. Breakage of the nightly builds needs to be fixed as soon as possible so that people can develop with the trunk without running into problems with code from others. The policies and guidelines at https://salilab.org/imp/doc/doxygen/devguide.html are largely unchanged. In particular, API changes to modules should still be announced on imp-dev (ideally when the interface is designed, before the code itself is written). API changes to the kernel also need to be announced on imp-dev before they are implemented; only if nobody objects within two working days to the change can it be applied. I have also created some new branches: - branches/stable is updated from trunk whenever the nightly builds pass. Thus, people like Frido can use branches/stable and do an 'svn up' confident that it works (at least for us). For example, 'svn co https://svn.salilab.org/imp/branches/stable' will check out the stable branch, while 'svn switch https://svn.salilab.org/imp/branches/stable .' run from within an existing checkout of the IMP trunk will switch it to the stable branch. Once checked out or switched, the stable branch works in just the same way as the trunk - you just can't make patches to it (development takes place on the trunk). - branches/salilab/ is a directory under which people can create their own branches for not yet published stuff that we cannot make public outside the lab yet. - branches/testing/ is a directory under which short-lived branches for development/testing can be created. Code need not compile or work. Such branches should be deleted or merged back into the trunk once the code stabilizes. testing branches are not built by the nightly builds, of course. The default access permissions now are that everybody can read everything in IMP, while those in a select 'imp-writers' group can write. Thus the imp-writers people can also create new branches under branches/salilab or branches/testing if they so desire. (I recommend that you do not create a branch unless you really need to, though - it's much easier to keep up with others if you work in the trunk.) Exceptions: - those outside the Sali lab cannot read or write branches/salilab/. - branches/stable is read only - development must occur in the trunk. - modules are always writable by their owners, even if they are not in the imp-writers group. - everybody can write into trunk/patches/, as is currently the case. imp-writers are those in the Sali lab that have asked for write access. To be added to this group, I would typically ask you to make your first few contributions via the 'old' mechanism (write a patch and put it in the patches directory) until you get the hang of how things work. Ben -- ben(a)salilab.org http://salilab.org/~ben/ "It is a capital mistake to theorize before one has data." - Sir Arthur Conan Doyle

1 0

deprecated classes
by Daniel Russel 20 Jan '09

20 Jan '09

There are a number of classes in IMP.core which have been marked as deprecated for a while. I would be good to get rid of them entirely before the first public release. I propose that after the first marked stable version (a concept which will be explained in a forthcoming email from Ben), I remove them from SVN. So please check your code to make sure you don't use them and if you do, start migrating to the replacement classes. You can find a list of such classes at <https://salilab.org/imp/doc/doxygen/deprecated.html> and you code should spit out warning messages whenever you create an instance of such a class.

1 0

providing more control over builds
by Daniel Russel 20 Jan '09

20 Jan '09

There is currently no way (as far as I can tell) to tell IMP to build a debug (non-optimized) version. I propose replacing the "release" configure option with a "build" option which can be one of - "debug" which makes a non-optimized version of the library with debugging symbols - "release" which makes an optimized version of the library but with runtime checks enabled - "fast" (or some better name, perhaps "ndebug") which used NDEBUG to disable runtime checks (and is optimized and doesn't have debugging symbols).

2 1

atom module
by Daniel Russel 20 Jan '09

20 Jan '09

Since we have various atomic functionality and are getting more, we should probably start the atom module. Initially it will just have AtomDecorator ResidueDecorator MolecularHierarchyDecorator I would be inclined to put a wrapper for the modeller pdb reader there too, so that we don't have modeller dependencies scattered throughout the example files.

2 3

molecular hierarchy helper methods
by Daniel Russel 20 Jan '09

20 Jan '09

We have been kind of inconsistent about molecularhierarchy-related helper methods, for example molecular_hierarchy_get_by_type. Some of the methods have a molecular_hierarchy_ prefix and some not. I propose (as was Ben's preference when this was discussed before) to remove the prefix from the methods which have it: molecular_hierarchy_get_by_type becomes get_by_type and molecular_hiearchy_get_residue becomes get_residue

2 1

Moving atom and residue types
by Daniel Russel 20 Jan '09

20 Jan '09

I moved the atom and residue predfined types from being static members of the respective decorator (i.e IMP::core::AtomDecorator::AT_C) to being members of the IMP::core namespace (IMP::core::AT_C) so that swig could manage to export them to python. This shouldn't affect too much code as they were not previously usable from python, but just be aware.

1 0

decorator improvements
by Daniel Russel 19 Jan '09

19 Jan '09

Most of the decorators now that things as arguments to their create function. For example, you can now do XYZDecorator.create(p, IMP.Vector3D(1,2,3)). Just something to be aware of. The IMP_DECORATOR macro also changed in case anyone else uses it. Read the documentation to see how to use the new one.

1 0