May 2009 - IMP-dev - salilab.org

measurement units in IMP
by Daniel Russel 14 May '09

14 May '09

Should we establish an explicit rule in IMP that all distances are in angstroms? The range of scales is small enough that we don't have accuracy issues for doing this. In addition, we then don't have to worry about some things being in nanometers (since we have no way of tagging things with units). Ben already established a convention of having units if kCal/MolAngstrom for derivative quantities. So angstroms fits with that.

4 4

Compiling error on Mac only?
by Seung Joong Kim 13 May '09

13 May '09

Today I updated IMP with the latest revision 2830, and I am having a compiling error on Mac only. It seems that there is a problem with the boost binding (I have installed boost version 1.38 by using Macport) Currently I don't have any problem with my linux machine. It happens only in my Mac.. Could you anyone figure out what was wrong? Thanks! - SJ g++ -o modules/atom/src/bond_graph.os -c -Woverloaded-virtual -Wall -O3 -fvisibility=hidden -fPIC -DNDEBUG -DIMP_LITTLE_ENDIAN -DIMPATOM_EXPORTS -DGCC_VISIBILITY -Ibuild/include -I/opt/local/include modules/atom/src/bond_graph.cpp build/include/IMP/internal/NestedIterator.h: In member function 'const IMP::internal::NestedIterator<T>& IMP::internal::NestedIterator<T>::operator++() [with T = IMP::atom::BondGraph::NestedTraits]': /opt/local/include/boost/concept_check.hpp:473: instantiated from 'boost::InputIterator<TT>::~InputIterator() [with TT = IMP::internal::NestedIterator<IMP::atom::BondGraph::NestedTraits>]' /opt/local/include/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::InputIterator<IMP::internal::NestedIterator<IMP::atom::BondGraph::NestedTraits> >]' /opt/local/include/boost/graph/graph_concepts.hpp:47: instantiated from 'boost::concepts::MultiPassInputIterator<T>::~MultiPassInputIterator() [with T = IMP::internal::NestedIterator<IMP::atom::BondGraph::NestedTraits>]' /opt/local/include/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::concepts::MultiPassInputIterator<IMP::internal::NestedIterator<IMP::atom::BondGraph::NestedTraits> >]' /opt/local/include/boost/graph/graph_concepts.hpp:219: instantiated from 'boost::concepts::EdgeListGraph<G>::~EdgeListGraph() [with G = IMP::atom::BondGraph]' /opt/local/include/boost/graph/graph_concepts.hpp:209: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::concepts::EdgeListGraphConcept<IMP::atom::BondGraph>]' /opt/local/include/boost/concept_check.hpp:43: instantiated from 'void boost::function_requires(Model*) [with Model = boost::concepts::EdgeListGraphConcept<IMP::atom::BondGraph>]' modules/atom/src/bond_graph.cpp:60: instantiated from here build/include/IMP/internal/NestedIterator.h:41: error: 'CGAL_assertion' was not declared in this scope /opt/local/include/boost/concept_check.hpp: In destructor 'boost::SignedInteger<T>::~SignedInteger() [with T = unsigned int]': /opt/local/include/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::SignedInteger<unsigned int>]' /opt/local/include/boost/concept_check.hpp:468: instantiated from 'boost::InputIterator<TT>::~InputIterator() [with TT = IMP::internal::IndexingIterator<IMP::atom::BondedDecorator::GetBonded>]' /opt/local/include/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::InputIterator<IMP::internal::IndexingIterator<IMP::atom::BondedDecorator::GetBonded> >]' /opt/local/include/boost/graph/graph_concepts.hpp:47: instantiated from 'boost::concepts::MultiPassInputIterator<T>::~MultiPassInputIterator() [with T = IMP::internal::IndexingIterator<IMP::atom::BondedDecorator::GetBonded>]' /opt/local/include/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::concepts::MultiPassInputIterator<IMP::internal::IndexingIterator<IMP::atom::BondedDecorator::GetBonded> >]' /opt/local/include/boost/graph/graph_concepts.hpp:148: instantiated from 'boost::concepts::AdjacencyGraph<G>::~AdjacencyGraph() [with G = IMP::atom::BondGraph]' /opt/local/include/boost/graph/graph_concepts.hpp:139: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::concepts::AdjacencyGraphConcept<IMP::atom::BondGraph>]' /opt/local/include/boost/concept_check.hpp:43: instantiated from 'void boost::function_requires(Model*) [with Model = boost::concepts::AdjacencyGraphConcept<IMP::atom::BondGraph>]' modules/atom/src/bond_graph.cpp:59: instantiated from here /opt/local/include/boost/concept_check.hpp:91: error: request for member 'error_type_must_be_a_signed_integer_type' in '((boost::SignedInteger<unsigned int>*)this)->boost::SignedInteger<unsigned int>::x', which is of non-class type 'unsigned int' /opt/local/include/boost/concept_check.hpp: In destructor 'boost::SignedInteger<T>::~SignedInteger() [with T = long unsigned int]': /opt/local/include/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::SignedInteger<long unsigned int>]' /opt/local/include/boost/concept_check.hpp:468: instantiated from 'boost::InputIterator<TT>::~InputIterator() [with TT = IMP::internal::NestedIterator<IMP::atom::BondGraph::NestedTraits>]' /opt/local/include/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::InputIterator<IMP::internal::NestedIterator<IMP::atom::BondGraph::NestedTraits> >]' /opt/local/include/boost/graph/graph_concepts.hpp:47: instantiated from 'boost::concepts::MultiPassInputIterator<T>::~MultiPassInputIterator() [with T = IMP::internal::NestedIterator<IMP::atom::BondGraph::NestedTraits>]' /opt/local/include/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::concepts::MultiPassInputIterator<IMP::internal::NestedIterator<IMP::atom::BondGraph::NestedTraits> >]' /opt/local/include/boost/graph/graph_concepts.hpp:219: instantiated from 'boost::concepts::EdgeListGraph<G>::~EdgeListGraph() [with G = IMP::atom::BondGraph]' /opt/local/include/boost/graph/graph_concepts.hpp:209: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::concepts::EdgeListGraphConcept<IMP::atom::BondGraph>]' /opt/local/include/boost/concept_check.hpp:43: instantiated from 'void boost::function_requires(Model*) [with Model = boost::concepts::EdgeListGraphConcept<IMP::atom::BondGraph>]' modules/atom/src/bond_graph.cpp:60: instantiated from here /opt/local/include/boost/concept_check.hpp:91: error: request for member 'error_type_must_be_a_signed_integer_type' in '((boost::SignedInteger<long unsigned int>*)this)->boost::SignedInteger<long unsigned int>::x', which is of non-class type 'long unsigned int' scons: *** [modules/atom/src/bond_graph.os] Error 1 scons: building terminated because of errors. -- Seung Joong Kim, Ph.D. Postdoctoral Scholar, Andrej Sali group Department of Biopharmaceutical Sciences, School of Pharmacy University of California at San Francisco (UCSF)

2 1

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