IMP-dev

imp-dev@salilab.org

869 discussions

recently in IMP
by Daniel Russel 10 Dec '10

10 Dec '10

- the biological systems specification has been improved a little adding ability to run some rudamentary tests to make sure the scripts are ok and to not require that everything be run from the svn directory. - A new method IMP::atom::create_compatible_rigid_body() which creates a rigid body from a hierarchy which has the same internal coordinates as another rigid body. A way to make the rigid body construction more canonical would be nice (so we don't need this function), but I'm not sure how to do that. - Logging has been improved to better report the name of methods producing the log messages - a macro IMP_FUNCTION_LOG has been added which should be added to the start of non-member functions which produce significant logging output. - IMP::algebra::get_distance(const Rotation3D&,const Rotation3D&) was changed to use the Euclidean distance in R4 as that seems better behaved than the prior metric. - IMP.domino2 was renamed to IMP.domino and the old IMP.domino was moved to https://svn.salilab.org/imp/branches/salilab/domino1 - the documentation for classes and some methods now includes a list of all examples which use the class. Please report any incorrect links or phantom classes appearing in the docs. Unfortunately, functions have to be added individually. Please request any functions of particular interest. - applications and biological systems now have their own documentatin pages

1 0

IMP build system thoughts
by Daniel Russel 24 Nov '10

24 Nov '10

I think it very important that people run their code with checks turned on at least once to make sure there aren't obvious usage errors and most people seem to want speed and hence also want to run production code against a fast IMP build. Has this been has the current setup discouraged anyone from doing multiple builds? Currently, having two separate builds requires doing something like: - svn co https://svn.salilab.org/imp/trunk imp - mkdir release - ./imp/tools/setup-out-of-source release - cd release - scons -j 4 config.py build=release path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include - scons -j 4 - ./tools/imppy.sh python myscript.py - mkdir fast - ./imp/tools/setup-out-of-source fast - cd fast - scons -j 4 config.py build=fast path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include - scons -j 4 - ./tools/imppy.sh python myscript.py It could be made easier eg: Options: 1) provide release and fast subdirectories in the svn checkout. This would be very easy to implement. Usage would then be something like, - svn co https://svn.salilab.org/imp/trunk imp - cd imp - ./configure path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include - cd release - scons -j 4 - ./imppy.sh python myscript.py - cd ../fast - scons -j 4 - ./imppy.sh python myscript.py Unfortunately with both this and the current setup, installing release and fast versions of IMP requires installing them in separate locations and then switching around your LD_LIBRARY_PATH and PYTHON_PATH to switch between them. But a model where by you run with release on your machine and fast on the cluster would work fine. We could provide imppy.sh equivalents for once IMP is installed. 2) use an environment or python variable to switch on load time (warning, I don't actually know how to implement this, but suspect it can be done). - svn co https://svn.salilab.org/imp/trunk imp - cd imp - scons config.py path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include or ./configure path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include - scons -j 4 #build both fast and release - ./tools/imppy.release.sh python myscript.sh - ./tools/imppy.fast.sh python myscript.sh One could then install IMP normally (there would be libs like lib_imp_fast and lib_imp_release) and the right one could be chosen at runtime with an environment variable (or perhaps something more clever entirely within python)

3 7

IMP 1.1 release thoughts
by Daniel Russel 23 Nov '10

23 Nov '10

Given that it has been a while since IMP 1.0 was released and IMP has improved a lot, I think we should have an IMP 1.1 release in the near future (say, on the order of a month). There are a few modules with fairly active development, which can either stabilized for a release or skipped from the release. The status of each modules as I understand it (ok means "no implementation plans/known important bugs"): - build system: ok - kernel: ok - cgal: volume/surface are computations are not heavily tested, but they are not a show stopper - algebra: ok - bullet: ok - display: ok - em2d: active development, Javi, what are your plans/goals? - modeller: ok - restrainer: ok - domino: should probably go away for the release - example: ok - multifit: active development. Keren, what are your plans/goals? - saxs: ok - atom: ok (recent development in the protein-ligand score, more bugs might be discovered there) - container: ok - domino2: ok (poor handling of nbls with rigid bodies, but I don't think it is a show stopper) - gsl: ok - statistics: ok - benchmark: ok - core: ok - em: discussed plans for moving to algebra::Grid3D and moving algorithms to algebra where they can be more widely used, but no implementation. This would be nice, and should be relatively quick, but not a show stopper, I think. - misc: ok - openmm: should not be part of release I'll make a pass through before the release to add more comments to example code (others feel free to contribute, please, please please :-) Other issues? Thanks.

4 4

proposed change for distance between two rotations
by Daniel Russel 18 Nov '10

18 Nov '10

Javi has pointed out that the current function to get distance between two rotations isn't very nicely behaved in that it doesn't get close to 0 until the rotations are really, really close to one another. Going back to the simpler formulation of distance as simply the euclidean norm between the two quaternions (properly signed) divided by the sqrt(2) (to keep it between 0 and 1) should improve things. Any comment/objections?

1 0

Let's postpone the IMP-dev meeting until next Tuesday
by Daniel Russel 16 Nov '10

16 Nov '10

Sorry, Fedex is being annoying and I have to wait for them.

1 0

domino goes out and domino2->domino
by Daniel Russel 16 Nov '10

16 Nov '10

IMP.domino2 was renamed to IMP.domino and the old IMP.domino was moved to https://svn.salilab.org/imp/branches/salilab/domino1 You may need to remove the modules/domino and modules/domino2 directories in order to update and remove build in order to get things to build cleanly.

2 1

Meeting tomorrow: What can we do to get people to post their scripts?
by Daniel Russel 15 Nov '10

15 Nov '10

one of the goals of the imp project is to encourage sharing of protocols for modeling biological systems. I'd like to have a discussion about what carrots can be offered to encourage people to share data and scripts and what requirements should be placed on the scripts to ensure that they are actually useful to others. proposed carrots: - providing hosting via svn - provide scripts to generate web pages and links from IMP doc to the systems web pages - scripts in svn can be kept in running order relatively easily by us proposed requirements for shared biological systems - documentation of authors, publications and an overview of the system - a script run.py which reproduces the final results (when run with "./tools/imppy.sh python run.py") 1pm Tuesday.

1 0

recently in IMP
by Daniel Russel 12 Nov '10

12 Nov '10

the documentation for classes and some methods now includes a list of all examples which use the class. Please report any incorrect links or phantom classes appearing in the docs. Unfortunately, functions have to be added individually. Please request any functions of particular interest. applications and biological systems now have their own documentation pages IMP::atom::Hierarchy requires radii on its leaves IMP::atom::read_pdb add radii to the atoms

1 0

localmodules->local
by Daniel Russel 11 Nov '10

11 Nov '10

I renamed the localmodules scons flag to local since we now have applications and biological systems in addition to modules and three flags seemed excessive. So do local=True if you have your own module, application or biological system you want scons to see. Also, building should work now. Complain if it doesn't.

1 0

I would suggest you don't do svn update
by Daniel Russel 10 Nov '10

10 Nov '10

I think I may have broken things and haven't had a chance to clean them up.

1 0

← Newer
1
...
25
26
27
28
29
30
31
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev