- IMP-dev - salilab.org

This week in IMP
by Daniel Russel 08 May '09

08 May '09

- There is a IMP::Rotation2D - You can now extract fixed Euler ZYZ angles from a IMP::Rotation3D. This code can serve as a template for extracting other Euler angle conventions if they are needed. - IMP::algebra::rotation_between_two_vectors() changed to IMP::algebra::rotation_taking_first_to_second() to make it clear which direction the rotation goes. - IMP::Decorator derived objects are now convertible to bool. So code like if (d) { blah } works. - IMP::Decorator::cast now returns a null decorator (\c DecoratorName()) rather than throwing an exception. This might make it actually useful. The previous method was entirely unused. - New IMP::statistics module for statistical methods (e.g. clustering).

1 0

Re: [IMP-dev] too many rotations in IMP
by Javier Ángel Velázquez Muriel 07 May '09

07 May '09

> > > 2009/5/4 Daniel Russel <drussel(a)gmail.com> > >> We already have constructing a Rotation3D from your choice of Euler >>> angles (and you can get a matrix from that if you want). So there isn't much >>> reason to be passing them around at all. >>> >>> No, that is not true. Given that no convention was established, there is >>> freedom to use anyone. >>> >> Yes, there is no convention for which types of Euler Angles to use. There >> is a convention that all rotations be represented using a Rotation3D (which >> can be created from many things). >> >> Sure, the question is more whether it should be part of the API or in an >>> internal header or .cpp file where it is used. So far I don't see anything >>> that justifies creating an alternative rotation passing convention (which >>> would require lots of functions to be eventually duplicated to support >>> both)._______________________________________________ >>> >>> I will be happy hearing about any improvement in the API. I'm worried >>> though about project(). It should work at least as it is working now, and >>> respecting my choice of angles and rotation interface requesting a matrix, >>> because that function is at the core of my project and I want that >>> performance. If it can be improved, I gladly will acknowledge any >>> contribution. As long as the function is able to access what requires, I >>> don't mind the way it is done. I can provide stringent tests that I decided >>> not to finally put in actual tests. >>> >> Given a relatively narrow interface, performance is generally pretty easy >> to achieve given a benchmark to test changes. The narrow interface is >> important since it means that you don't have to improve up too much code (eg >> having several Rotation classes means improvements to one are not available >> to functions which use another). >> > I agree. > >> >> As I mentioned, we can always add an internal cache of the matrix values >> in Rotation3D if we find that such speeds things up. My suspicion is that >> the compiler would cache the results for us if you are applying the >> rotations in an inner loop and that the memory accesses would overwhelm the >> reduced number of multiplications if it is not, but it is easy to test once >> a benchmark is set up. For this, a benchmark of just rotating a matrix of >> random numbers would probably do and be very easy to set up. > > I will be very happy to hear from that. > >> >> >> It seems to me the old interface with >> - Rotation3D which has a rotate function >> - functions to create Rotation3Ds from various Euler angles (including >> ZYZ, if it is not already there) >> - possible caching of the rotation matrix in Rotation3D if that does speed >> things up >> covers everything that is needed without the addition of any of the new >> classes and conflicting conventions. Is this right? >> > > No. I tried building a Rotation 3D and using it and it didn't work with > project(). I can provide the details of what was failing, and maybe somebody > can find what I couldn't after fighting for some weeks. It would be very > helpful. > > >> Then anyone can, upon reading Euler angle values (of whatever convention) >> create a Rotation3D. This Rotation3D can be used to perform rotations in an >> efficient manner. And we don't have to worry about some functions take one >> representation for rotations, and some another. > > > Fine, as long as project() can be accessed the way I want/need and works > after the changes, I don't mind the internal way it calls rotations. > > > >> >> _______________________________________________ >> >> IMP-dev mailing list >> IMP-dev(a)salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > >

3 11

specifying input files in IMP
by Daniel Russel 05 May '09

05 May '09

Currently files which need input files take strings with the path to the file name. This is pretty easy, but eliminates the possibility of using more exotic sources and write destinations (such as reading and writing from memory). Since Ben has gotten streams working across the C++/Python bridge, we could switch our interfaces over to using streams everywhere. Thoughts?

4 4

too many rotations in IMP
by Daniel Russel 04 May '09

04 May '09

I think we currently have too many way of representing matrices in the IMP API. - Rotation3D - EulerAnglesZYZ - and EulerMatrix The last doesn't make any sense as there is no reason to tie together two disparate representations. Given that one can create a Rotation3D from Euler angles I don't see any reason to expose the second. If we find rotational matrices are faster than quaternions for actually performing the rotations, then we should cache the matrix in Rotation3D rather than add another class. Comments? Justifications for having many different versions?

3 7

New 'statistics' module
by Ben Webb 01 May '09

01 May '09

Anybody have any objection to creating a new IMP.statistics module? Keren's k-means stuff in DOMINO is not specific to DOMINO, and so should probably belong in a more general purpose module. And I'm sure we'll need various other samplers and clustering algorithms in the future. If no objections, I'll create the module so that Keren move her code there. Ben -- ben(a)salilab.org http://salilab.org/~ben/ "It is a capital mistake to theorize before one has data." - Sir Arthur Conan Doyle

3 4

Merge of EMBED into IMP
by Ben Webb 28 Apr '09

28 Apr '09

Just FYI, as previously discussed I will be merging the EMBED library into the IMP.em module sometime tomorrow. There should be little user-visible change - there will simply be no need to compile EMBED separately any more. On the IMP side, there will be a jump in revision numbers after the EMBED history is added, of course. On the EMBED side, I will make the repository read-only after the merge. Ben -- ben(a)salilab.org http://salilab.org/~ben/ "It is a capital mistake to theorize before one has data." - Sir Arthur Conan Doyle

4 11

IMP and GPL dependencies
by Daniel Russel 28 Apr '09

28 Apr '09

We keep bumping into the useful libraries that are GPL (most recently FFTW, which is GPL with commercial licenses available). My proposal is that we allow dependencies against such libraries as long as - the code which depends on the library is gathered into a self contained module which is, itself, GPL and - IMP as a whole does not require the library to function, only certain functionality is missing The reason for this suggestion is that - the LGPL, under which we plan to license IMP, allows the code under it to be relicensed under GPL - most people in a research environment will not care if their resulting application is GPL or LGPL - reimplenenting things ourselves is a pain and best put off until we really need to create an application which is not GPL (for example linking with Chimera).

2 5

Data files in IMP
by Daniel Russel 28 Apr '09

28 Apr '09

Dina has run into the need to add data files to IMP (specifically for bond topology). There are a number of options that I see for this, but none of them are idea. The important properties that I see are: - users (and their scripts/config files) should only every have to specify paths to files that are theirs (no paths to things that are part of IMP) - it should be possible to debug IMP without installing it so that you don't have to worry about which copy of the header file you are editing The two choices that I see which satisfy these criteria are: - embed all data into the data section of the libraries. This presents the simplest view to users: standard data that are part of IMP just work. Most data files can be embedded as a string variable (perhaps with some escaping,which could be done by a script) and then read using a string stream. The disadvantage is that the data files are not accessible to the users so they can't easily create patched versions. While this is generally not a problem, the API design would have to take this into account (and allow the user to specify multiple data sources at once or apply the operation successively with different data sources). - IMP is built with the path to the data stored internally and it must be installed before use. The build dir could be a special install target which then doesn't copy the headers or libs since the links are already there. imppy.sh could go away on most platforms as we could safetly embed the paths to the build/lib dir as the library will be rebuild before being installed

2 3

Compiling error?
by Seung Joong Kim 27 Apr '09

27 Apr '09

Hi all, I keep getting a compiling error on my Mac and linux, since yesterday. Is there anyone who has the same problem? Did I miss some essential configurations? g++ -pthread -o modules/search/pyext/search_wrap.os -c -O3 -fPIC -fno-strict-aliasing -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -DNDEBUG -DIMP_LITTLE_ENDIAN -DIMP_SWIG_WRAPPER -Ibuild/include -I. -I/usr/include/python2.5 modules/search/pyext/search_wrap.cc benchmarks/random_collisions.cpp: In function 'int main()': benchmarks/random_collisions.cpp:62: error: 'BoxSweepClosePairsFinder' was not declared in this scope benchmarks/random_collisions.cpp:62: error: 'cpf' was not declared in this scope benchmarks/random_collisions.cpp:62: error: expected type-specifier before 'BoxSweepClosePairsFinder' benchmarks/random_collisions.cpp:62: error: expected `;' before 'BoxSweepClosePairsFinder' g++ -o benchmarks/connectivity benchmarks/connectivity.o -Lbuild/lib -limp -limp_misc -limp_domino -limp_core -limp_atom -limp_algebra -limp scons: *** [benchmarks/random_collisions.o] Error 1 scons: building terminated because of errors. Thanks a lot! -- Seung Joong Kim, Ph.D. Postdoctoral Scholar, Andrej Sali group Department of Biopharmaceutical Sciences, School of Pharmacy University of California at San Francisco (UCSF)

3 5

FFTW license
by Javier Ángel Velázquez Muriel 27 Apr '09

27 Apr '09

Ben, I'm going to need a FFT library. Is FFTW a possibility (Daniel says there are workarounds) or would you suggest something else? Javi

2 1