IMP-dev April 2009

imp-dev@salilab.org

6 participants
19 discussions

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

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

modeller dependency
by Keren Lasker 25 Apr '09

25 Apr '09

hi, Currently building IMP fails if modeller is not installed ( required by benchmarks/connectivity.o) Keren.

3 2

This week in IMP
by Daniel Russel 24 Apr '09

24 Apr '09

- Support for taking advantage of rigid bodies in collision detection has been added via the IMP::core::RigidClosePairsFinder<https://salilab.org/imp/doc/doxygen/classIMP_1_1core_1_1RigidClosePairsFind…> . - All IMP::core::ClosePairsScoreState<https://salilab.org/imp/doc/doxygen/classIMP_1_1core_1_1ClosePairsScoreStat…>-related functinality has been optimized and should be noticeably faster. - The EMBED project has been merged into the IMP::em<https://salilab.org/imp/doc/doxygen/namespaceIMP_1_1em.html>module. Thus, it is no longer necessary to obtain EMBED separately to build IMP::em <https://salilab.org/imp/doc/doxygen/namespaceIMP_1_1em.html>. - All C++ methods which work with std::istream or std::ostream arguments should now be usable from Python: any Python file-like object can be used. - The SWIG interface now ties in to the reference counting mechanism used in the C++ code, for all classes derived from IMP::RefCounted<https://salilab.org/imp/doc/doxygen/classIMP_1_1RefCounted.html>. So, for example, deleting a Python object should not free the underlying C++ object if another C++ object holds a reference to it, and unrefing a C++ object should not delete it if a Python object still holds a reference to it. There should be no further need to manually keep references to Python objects to prevent things from being prematurely cleaned up. This should be transparent to the user; please report any problems. - IMP::atom::AtomDecorator<https://salilab.org/imp/doc/doxygen/classIMP_1_1atom_1_1AtomDecorator.html>no longer inherits from IMP::core::XYZDecorator<https://salilab.org/imp/doc/doxygen/classIMP_1_1core_1_1XYZDecorator.html> .

1 0

default epsilon ?
by Javier Ángel Velázquez Muriel 23 Apr '09

23 Apr '09

Hi all I am going to suggest something that is not very "correct", but that it is already "de facto" in IMP. I would suggest a default epsilon value for the cases where the use of "almost_equal" function cannot be avoided. That is dangerous, I know, but I think it is even more dangerous to have the code full of different epsilons if they don't need to be different. I'm saying this because IMP::em already has a EPS value of 1e-6 that is thoroughly used, and probably makes sense to define one EPS in other modules. My need is to compute the correlation between two em::Images, that in fact is going to be the correlation between their algebra::MultiArrays containing the data, and I need to check for values of the standard deviation (which is a double) near zero. I don't see how to avoid the use of almost_equal() here, and again, a default epsilon for IMP::algebra sounds reasonable to me.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev April 2009