IMP-dev

imp-dev@salilab.org

869 discussions

Proposed cleanup of MonteCarlo movers
by Daniel Russel 12 Mar '13

12 Mar '13

I'd like to clean up the Monte Carlo mover support in a relatively minor but non-backwards-compatible way. This is motivated by - the current interface is a significant fraction occupied by stuff that is just there for backwards compatibility (eg the size parameter for propose_move()) - there is interest in supporting asymmetrical movers, which requires that propose_move() return an additional value (which would be 1.0 for all existing movers) I don't think there are too many movers outside of ISD, ISD2 and membrane, all of which I can update, and use of the movers would be unchanged, so I don't expect that such a change would be painful. If it is problematic, then I can provide a backwards compatibility layer, but that adds complexity and confuses the API and so would be nice to avoid. Comments? The new mover would look like: class Mover: public ModelObject { public: MoverResult propose_move(); void reject_proposed_move(); void accept_proposed_move(); protected: virtual MoverResult do_propose_move()=0; virtual void do_reject_proposed_move()=0; virtual void do_accept_proposed_move()=0; }; class MoverResult { ParticlesTemp get_moved_particles() const; double get_move_probability() const; /* Yannick has a better name for this */ };

1 0

Recently in IMP
by Daniel Russel 17 Feb '13

17 Feb '13

I have started working on an updated introduction to IMP. The current version can be found here <https://github.com/salilab/imp/wiki/Introduction-2>. All comments are encouraged, as well as direct improvements in the wiki. Recently in IMP: - You can now (probably) build IMP with CMake. See <https://github.com/salilab/imp/wiki/Cmake> - The maximum logging level and check level can now be controlled independently of the build mode. To, for example, enable progress level logging in a fast build, add maxlog="PROGRESS" to your config. The maximum check level for `release` has been reduced to IMP::USAGE as that speeds things up a bit. - The way applications are structured an specified has been regularized and simplified. Python files are automatically copied/installed and binary executables are compiled from each found `.cpp` file linked with any `.cpp` files contained in a subdirectory called `lib`. Nothing needs to be put into the SConscript file. - The python constants like IMP.algebra.has_cgal went away as swig autogenerates ones like IMP.algebra.IMP_ALGEBRA_HAS_IMP_CGAL. While the latter are a bit uglier, the constants aren't used much and have them be auto generated in nice. - There have been some major changes to the build system. The main one is that the SConscripts in the directories below the module directory aren't really used. They are being removed from the repository. Now everything really is off of file locations (eg all test_* in test is a test, each *.cpp in bin becomes a program etc). This greatly simplifies the build system, which has, historically been a disaster. You can now define dependencies by dropping files into a dependency subdirectory in your module, no need to mess with the SConscript. - Building IMP now always requires specifying a `repository` argument. This was always required for out of source builds, which is what one should be doing, but is now required for in source builds to, so as to make accidentally poluting your source with an in-source build harder. Use `repository="."` in that case. -...

1 0

Requiring an extra step to do an in-source build of IMP
by Daniel Russel 31 Jan '13

31 Jan '13

Once you run scons in your IMP source directory, it is hard to get the source directory back into a state where you can do an out of source build, and, in general, the easiest is to simply check IMP out again. In addition, the failure modes when attempting an out of source build are rather odd. Since quite a number of people have run into this problem, and in-source builds of IMP are not something we want to encourage, I'd like to change the behavior a bit: - make the repository argument required. You can use "." if you want to do an in-source build - print an error message and terminate the build immediately with a message to the effect that "You should do an out of source build. If you, for some reason, really want to do an in-source build, add repository=. to your config." Seem reasonable?

1 0

Recently in IMP
by Daniel Russel 23 Jan '13

23 Jan '13

- Support for \imp-wide command line flags have been added to IMP::base in the base/flags.h file. They provide a simple command line parsing interface that can be used from C++ and python. In addition, various functionality in \imp is automatically exposed on the commend line when those functions are used. For example, one can control logging, checks or profiling. See IMP/base/flags.h for (some) more info. - OpenMP support in IMP is officially released. All tests pass. But there has been little specific testing so far. - Access to attributes using IMP::ParticleIndex and the IMP::Model now works from Python. See IMP::Model::add_attribute() and kin. - IMP::ParticleKey and IMP::ParticlesKey were renamed to IMP::ParticleIndexKey and IMP::ParticleIndexesKey respectively as that is what they store. Typedefs were provided to support old code. - Indexes have been added to the docs connecting classes with all the methods that return them, examples that use them and methods that take them. And all methods that are used in examples with the examples they are used in. Please check them out and report issues and ways to improve things. You can find links on the main page. - The docs for a modules/biological systems/applications should now be found in an `overview.dox` in the module `doc` folder. Modules in \imp svn have been updated. For external modules, you can just move a `overview.dox` from that was previously generated into your `doc` folder and (eventually) remove the lines from your `doc/SConscript`. This makes it easier to use the full range of doxygen markup, as well as removes the need to escape doxygen markup for python. - Examples have now been simplified into full blown doxygen examples. This involves merging the `.py` and `.readme` files (putting `\#\#` in front of each line of the `.readme`) and adding a `## \\example module/examplename.py` line at the begginning. You can use `./tools/updaters/update_examples.py modules/mymodule` to update a module that was not already updated. - IMP::base::FailureHandler has been removed as it wasn't used. - Handling of data and includes has been simplified. All appropriate files in the corresponding directories are linked into build/installed. This is only likely to be a problem if you had broken headers sitting around `include`. If so, just `\#if 0` them out, or move them some place nicer. - Modules now must be in a folder called `modules`, which must have an `SConscript` file. - The build system should now be a little better about cleaning up after itself. - How headers/doc files/data/examples - The IMP_PROTECTED macros didn't work out well, and are now deprecated. Sorry. If you had python implementations on top of IMP base classes that implement protected virtual methods, you may need to remove a leading "_" on the method name. - Nice version numbers will now be generated if you use git. You need to rerun tools/git/developer_tools/init_git if you have an existings clone.

1 0

And more simplifications
by Daniel Russel 15 Jan '13

15 Jan '13

To help reduce the amount of logic that is in your crazy mess of a build script and to take advantage of improvements in doxygen, I'd like make 2 changes: - instead of examples having a separate readme file, they will be more normal doxygen examples that start with a comment and an \example line with the files name (like headers do) - module overview information will be stored in a file called overview.dox that you can edit directly, rather than have it be generated from data passed to SConscript. The data has to be escaped properly and is kind of a pain to deal with. Both of these I will do for all the modules in the repository and I'll provide a script that can update the example files of a given model for modules that are elsewhere (since I have to interest in making such changes myself anyway :-). I don't expect this to cause problems since I don't think people other than us generate docs.

1 0

More proposed simplifications to IMP
by Daniel Russel 15 Jan '13

15 Jan '13

I'd like to remove support for explicitly listing headers/source files in SConscript files. The default behavior, and the one we recommend that people use is that the SConscript simply finds all the .cpp or .h files in the appropriate directories (like how it finds all tests in the test directory). Since broken .cpp or .h files mixed in with the real source make reading/greping the code more confusing and they can easily be moved elsewhere there isn't really much point in the excluding files by not listing them. And it creates the prospect for bugs when headers or source files are left out of the list. Let me know if there are any objections.

1 0

Proposed removals from IMP
by Daniel Russel 14 Jan '13

14 Jan '13

As part of a cleanup on various things IMP, I'd like to remove the following bits of functionality that I suspect are unused/ or are problematic - FailureHandler: I don't think anyone uses this functionality - the ability to define modules in arbitrary locations (outside a modules folder or as part of a biological system): this will require a small amount of work for people who build modules externally to IMP (since they will have to put their module into a folder called modules if it isn't there already). But doing so would allow us to move a bunch of logic out of scons (which is really slow) and would simplify builds. - application of IMP_PROTECTED to virtual methods: adding this wasn't a terribly good idea on my part. SWIG will wrap protected virtual methods and we don't have enough non-virtual protected methods to be too interesting. And the existing macros (and any way I can figure out how to implement them) messes with Doxygen.

1 0

FAQ for developers
by Javier Velazquez 08 Jan '13

08 Jan '13

Hi Daniel and I have started a FAQ section for developers in the github wiki for IMP. Here https://github.com/salilab/imp/wiki/FAQ-for-developers It is intended to include those somewhat detailed or tricky things that you were fighting with until you asked Daniel or just figure them out yourself. If you have some, put them there. It will help others. The FAQ section is not intended to contain any tutorial questions. Just code problems / bugs / why your are getting those beautiful segfaults, etc ...

1 0

Warning about building imp on the cluster
by Daniel Russel 12 Nov '12

12 Nov '12

RMF needs cmake 2.8 and the default installed version is 2.6 (which is rather diffferent than 2.8). On int64a you can pass cmake="cmake28" to scons to have it find cmake 2.8 properly. Lab workstations and macs and everything else has new enough versions.

1 0

Re: [IMP-dev] IMP-dev meeting tomorrow
by Barak Raveh 16 Oct '12

16 Oct '12

Hi Daniel, Could we keep it for lunch as originally planned? We can have it while eating in the group meeting room if it's free, but then 1pm is probably a better hour Barak On Mon, Oct 15, 2012 at 10:54 AM, Daniel Russel <drussel(a)gmail.com> wrote: > Will be in the usual group meeting slot and room, since group meeting took > ours :-) > > > > > > > -- Barak

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
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