- IMP-dev - salilab.org

can a restraint be in more than one restraintset?
by Keren Lasker 08 Sep '11

08 Sep '11

does it mean the restraint is going to be evaluated twice?

2 5

recently in IMP
by Daniel Russel 08 Sep '11

08 Sep '11

- The RMF base support (stuff in the ::RMF namespace), has been moved to a new module, simply called RMF (no IMP). Now the functionality should be called like RMF.open_rmf_file() and headers include like \c RMF/RootHandle.h. This most was done in order to make the spin off of the RMF library as transparent as possible when it occurs later. - to work around various issues with ref counting pointers and compiler eccentricities, we added emulation of the C++0x \c nullptr. You should prefer that to \c NULL in \imp code that you want to run cross platform. - IMP::IntsList, IMP::FloatsList and IMP::StringsList have been added to replace the various scattered solutions for passing such types. - ::RMF::HDF5DataSetD is now templated on the dimension. Typedefs have been provided for the basic types so you can create an ::RMF::HDF5IndexDataSet2D now. - Various low level classes of IMP::rmf have been moved to the plain old ::RMF namespace as pat of cleaning things up to separate the RMF low level library from \imp. This include ::RMF::HDF5DataSetD. - IMP::Restraint::get_decomposition() and IMP::Restraint::get_current_decomposition() changed to return a single Restraint, instead of a list. This makes it easier to propagate the weight and maximum reliably. - \imp now supports usage of restraints without adding them to the IMP::Model scoring function. To do this, do IMP::Restraint::set_model(), passing the model. The restraint can then be evaluated. - IMP::domino::DominoSampler does not use the IMP::domino::OptimizeRestraints restraint optimization by default. Instead, if it is asked to create the IMP::domino::RestraintScoreSubsetFilterTable, it decomposes the restraints first (via IMP::create_decomposition()). This avoids several bugs and very fragile code. - the IMP::core::DiameterRestraint was ignoring the radii of the particles involved and so was giving artifically low scores. It now is on the actual diameter of this molecule. - the IMP::core::MonteCarlo optimizers now support incremental evaluation. This can be a lot faster when only a few particles are moved each step. - all the plural types in IMP have moved to bounds checked vectors when using debug builds with gcc. If you get a non-imp error about an invalid access, it is probably some code that walks off the end of an array. Please report it. - RMF::KeyCategory was renamed to RMF::Category - The deprecated constructors for various rmf/hdf5 things from files have been removed. Now use the methods RMF::open_rmf_file(), RMF::create_rmf_file(), RMF::open_rmf_file_read_only(), RMF::open_hdf5_file(), RMF::create_hdf5_file(). - RMF:: broke backward compatibility in order to accelerate loading times of files and use a more compact storage for strings. - The IMP::core::MoverBase was changed to move it off of the IMP::SingletonContainer. This resulted in the IMP::core::BallMover and IMP::core::NormalMover having new constructors. Now create them from a list of particles, a list of float keys and a radius/standard deviation. This removes some complexity and inefficiencies as well is removes some scope for errors. - Temp and non-temp decorator lists have been merged in C++. This was done to simplifity code since no one was using the non-temp variants. Now all decorator lists are temp (non-reference counted) variants. - restraints and restraint sets are now evaluated only using "canonical" weights. That is, each restraint has one weight for the model (the total over all the restraint sets it is contained in and will always be evaluated with that weight). This allows the evaluation of simple restraints to be faster. - The IMP_LIST() macros have been changed slightly. If your usage needs to take action upon addition, removal or changes to the list, use the IMP_LIST_ACTION() variant in your header. The IMP_LIST_IMPL() macro no longer takes the actions, and the last three (generally empty arguments) will have to be removed from the call to get it to work. This is needed to move towards more flexible and efficient passing of lists of values.

1 0

::rmf -> ::RMF
by Daniel Russel 01 Sep '11

01 Sep '11

Sorry I forgot to send this earlier. I had to rename the non-IMP rmf namespace to RMF to get around some bugs in old versions of swig. So now IMP RMF functionality is in ::IMP::rmf and non-imp functionality is in ::RMF.

1 0

minor change affecting HDF5AssignmentContainers
by Daniel Russel 31 Aug '11

31 Aug '11

There have been some changes to the rmf module that have some minor affects on how one would write assignments to a file or construct an assignment hdf5 container. The main difference is that to construct/open a data set for writing, you append _2d to the function call, rather than pass an argument of 2. eg data_set= rt.add_child_index_data_set_2d("node_1_assignments") If you do it in C++, the data set type is now ::rmf::HDF5IndexDataSet2D or ::rmf::HDF5DataSetD<::rmf::IndexTraits, 2>.

1 0

writing .cpp applications for IMP
by Daniel Russel 22 Aug '11

22 Aug '11

The new Mac OS runtime (as of 10.7) doesn't print out the error messages for uncaught exceptions and instead just gives a very cryptic and unhelpful message about an exception being thrown, with no more details. This unhelpful behavior can include uncaught exceptions when program_options doesn't find what it wants. As a result, it is a good idea to make sure the code in your .cpp mains in enclosed in a try/catch block that prints out the message. Something like int main(int argc, char **argv) { try { do stuff... return 0; } } catch (const IMP::Exception &e) { std::cerr << "Error: " << e.what() << std::endl; return 1; } catch (const std::exception &e) { std::cerr << "Error: " << e.what() << std::endl; return 1; }

1 0

recently in IMP
by Daniel Russel 21 Aug '11

21 Aug '11

- the IMP::core::MonteCarlo optimizers now support incremental evaluation. This can be a lot faster when only a few particles are moved each step. - all the plural types in IMP have moved to bounds checked vectors when using debug builds with gcc. If you get a non-imp error about an invalid access, it is probably some code that walks off the end of an array. Please report it. - IMP::rmf::KeyCategory was renamed to IMP::rmf::Category - The deprecated constructors for various rmf/hdf5 things from files have been removed. Now use the methods IMP::rmf::open_rmf_file(), IMP::rmf::create_rmf_file(), IMP::rmf::open_rmf_file_read_only(), IMP::rmf::open_hdf5_file(), IMP::rmf::create_hdf5_file(). - IMP::rmf broke backward compatibility in order to accelerate loading times of files and use a more compact storage for strings. - The IMP::core::MoverBase was changed to move it off of the IMP::SingletonContainer. This resulted in the IMP::core::BallMover and IMP::core::NormalMover having new constructors. Now create them from a list of particles, a list of float keys and a radius/standard deviation. This removes some complexity and inefficiencies as well is removes some scope for errors. - Temp and non-temp decorator lists have been merged in C++. This was done to simplifity code since no one was using the non-temp variants. Now all decorator lists are temp (non-reference counted) variants. - restraints and restraint sets are now evaluated only using "canonical" weights. That is, each restraint has one weight for the model (the total over all the restraint sets it is contained in and will always be evaluated with that weight). This allows the evaluation of simple restraints to be faster. - The IMP_LIST() macros have been changed slightly. If your usage needs to take action upon addition, removal or changes to the list, use the IMP_LIST_ACTION() variant in your header. The IMP_LIST_IMPL() macro no longer takes the actions, and the last three (generally empty arguments) will have to be removed from the call to get it to work. This is needed to move towards more flexible and efficient passing of lists of values. - IMP::rmf::create_hdf5_file() and IMP::rmf::open_hdf5_file() were added to avoid the dangerous and unclear bool paramter on the HDF5Group constructor. That constructor has been deprecated. - IMP::domino uses the new IMP::Model::evaluate_if_good() support to accelerate computations - IMP::core::MonteCarlo can use the IMP::Model::evaluate_if_good() support to more quickly reject very bad conformations. See IMP::core::MonteCarlo::set_maximum_difference(). - IMP::core::ExcludedVolumeRestraint has been rewritten to be faster. It is especially faster when used with IMP::Model::evaluate_if_good() - a new evaluation mode IMP::Model::evaluate_if_good() and IMP::Model::evaluate_if_below() has been added. It allows restraints to shortcut score computation when the score can be shown to be worse than a maximum value. - as part of moving towards more efficient use of evaluate_if_good() various deprecated methods have been removed from IMP::core::ExcludedVolumeRestraint and IMP::core::RigidClosePairsFinder. - incremental evaluation support was removed from \imp. The reason for doing this was that the code was complicated, created overhead even when incremental support was not used and was not commonly used. Further, decomposing the restraints and using the dependency graph yields similar results and is more transparent.

2 1

Want to build IMP in 1 minute from scratch?
by Daniel Russel 19 Aug '11

19 Aug '11

I've set up a ccache repository for IMP. Instructions for using it can be found at <https://salilab.org/internal/wiki/drussel/ccache>. I'm planning on having a cron job on my desktop that build IMP every morning, so things should always be relatively fresh. There may be lurking issues, so please pay attention and let me know if you encounter any strange behavior.

1 0

Now is not a good time to update IMP
by Daniel Russel 19 Aug '11

19 Aug '11

There is something subtle going on with memory that snuck in, I'm trying to track it down. Sorry.

1 1

Volume calculation for an elongated protein in IMP?
by Seung Joong Kim 09 Aug '11

09 Aug '11

Hi all, It seems to me that the current volume calculation in IMP EM module is based on a globular protein/complex shape (assuming 1.2 cubic angstrom per dalton), not applicable to an elongated protein such as Amelogenin. I compared UCSF chimera and it reported ~half size volume for the same density map and threshold. I don't know in detail how Chimera calculates volume for the density map of an elongated protein, but it would be great if we can add this function (or any other method that we can trust for an elongated /extended protein) to IMP. Any suggestions? Thanks! - SJ -- Seung Joong Kim, Ph.D. Postdoctoral Scholar, Andrej Sali group Department of Bioengineering and Therapeutic Sciences University of California at San Francisco (UCSF) 1-217-649-2147

2 1

proposal to simplify implementation of collections of decorators and particles
by Daniel Russel 05 Aug '11

05 Aug '11

Currently, lists of decorators and particles in IMP are implemented using some rather complicated an brittle custom containers and a reasonable runtime cost for iterating through Particles and Decorators. I would like to remove this code and replace the implementations by plain std::vectors (and std::vector<Pointer> when reference counting is needed). This would result in no difference to the python API, which does not use these containers at all. On the C++ side, there would be some significant changes, in particular - atom::Hierarchies would no longer inherit from core::Hierarchies and core::XYZRs would no longer inherit from core::XYZs, so certain code which assumes an implicit conversion from one to the other would break. Fixing the code would require addding IMP::get_as calls and a copy, or, ultimately better, just storing Particles and ParticlesTemp objects and constructing the decorators on demand - Particles no longer would inhertit from ParticlesTemp, so similar implicit conversions from one to the other would need get_as calls (which would result in a copy). From perusing the code, most of these conversions are occur in places when a Particles could be replaced by a ParticlesTemp with no loss of functionality (and a marginal speedup). These changes are likely to require many straight forward changes to existing code. So I'm a bit ambivalent.

2 2