August 2011 - IMP-dev

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

rmf warning
by Daniel Russel 04 Aug '11

04 Aug '11

Unfortunately, I need to make changes to the RMF file format that are not backward compatible. Let me know if you have data saved in rmf that you need to access and I'll work on a work-around. Otherwise, backward compatibility will be lost on your next svn update. Sorry about that, the change is needed to make reading certain large rmf files tolerably fast. The changes will include various other minor changes to make the format more space efficient and support other architectures.

1 0

Adding a restraint to more than one RestraintSet
by Daniel Russel 04 Aug '11

04 Aug '11

Does anyone use this ability? Removing it would simplify various things.

3 2