IMP-dev August 2009

imp-dev@salilab.org

4 participants
12 discussions

Last week in IMP
by Daniel Russel 31 Aug '09

31 Aug '09

- each module now has a version, eg IMP::get_module_version_info() which is also returned by the various restraints of the module. The python code checkes that loaded libraries have the expected version numbers to try to provide better messages when errors in path link result in linking against the wrong version of IMP. - the various ::bounding_box() methods have been renamed to ::get_bounding_box() to be more consistent with the other names. - python documentation is now parsed by doxygen

1 0

Last week in IMP
by Daniel Russel 14 Aug '09

14 Aug '09

• IMP::atom::read_pdb() now has some documentation concerning what it produces, especially in regards to HETATM records. In brief, ligands are put intoIMP::atom::Residue along with actual residues (amino acids and nucleotides). The RESIDUE IMP::atom::Hierarchy::Type has been renamed to AMINOACIDand a type LIGAND has been added. See the IMP::atom::Hierarchy docs. • IMP::atom::Mass has been added for decorating particles with mas. IMP::atom::Atom mass has been changed to use that. Non-atomic representations of molecules should also use that decorator. • The way to generate IMP::atom::AtomType strings from non-residue atoms has now been specified. Code which produces/consumes such atoms should follow the conventions.. • IMP::atom::get_chain() now returns an IMP::atom::Chain. IMP::atom::root() was renamed to IMP::atom::get_root() for consistency. • swig files are now generated from a file called swig.i in the pyext directory. This file only has to contain module-specific commands such as lines to wrap headers and instantiate module templates. No more broiler-plate. • the contents of bin are moving to tools since the two directories both contained assorted development tools (not all of which were executable). For now, bin/imppy.sh will still work, but that will go away eventually. It really shouldn't be used outside of IMP development anyway. • IMP::Decorator::show() now just takes the stream (it used to take a prefix also, which was often ignored). Anyone who implemented a decorator will have to delete the second argument of their show function. Please make sure any behavior that you depend on of code in IMP is well documented. Documentation is the only way to tell what is intended behavior from what just happens to be that way as a result of how things are implemented. The latter should not be counted on to stay stable.

1 0

For anyone who implemented a decorator
by Daniel Russel 11 Aug '09

11 Aug '09

Next time you update (and build) it will complain that the "show" function that you implement for your decorator has the wrong signature. Simply remove the prefix parameter (the std::string one) that you were probably ignoring anyway. The job of that parameter is now handler internally.

1 0

Last week in IMP
by Daniel Russel 08 Aug '09

08 Aug '09

Containers now have methods IMP::SingletonContainer::evaluate(), IMP::PairContainer::evaluate(), IMP::SingletonContainer::apply() and IMP::PairContainer::apply(). Using these can be significantly faster than looping over the particles externally. Similarly, there is IMP::SingletonScore::evaluate(), IMP::PairScore::evaluate(),IMP::SingletonModifier::apply(), IMP::PairModifier::apply(). The decorator functions have been renamed to IMP::Decorator::setup_particle(), IMP::Decorator::decorate_particle() and IMP::Decorator::particle_is_instance(). A shell script tools/ update-decorators is provided which updates the names in all code in subdirectories of the current directory. Please backup things first. a function, IMP::Restraint::safe_evaluate() has been added to be used when requesting the value of restraints outside of the IMP::Model::evaluate().

1 0

Atom::create
by Keren Lasker 07 Aug '09

07 Aug '09

seems that now element is needed for writing atoms in pdb format. Would not it make sense to set the value of element in Atom::create()?

4 33

SingletonFunctor
by Keren Lasker 07 Aug '09

07 Aug '09

Daniel - why is it better using: IMP_NEW(core::Transform, tsm,(t)); for(Particles::iterator it = ps.begin(); it != ps.end();it++) { tsm->apply(*it); } instead of: std::for_each(ps.begin(),ps.end(),SingletonFunctor(new IMP::core::Transform(t))); I saw you changed it in domino . thanks, Keren.

3 6

DecoratorBase
by Keren Lasker 07 Aug '09

07 Aug '09

Daniel - Just updated IMP .... I get an error DecoratorBase not found are there some files missing ? Keren.

2 3

Decorator function names
by Daniel Russel 06 Aug '09

06 Aug '09

As Javi just pointed out, the names (create, cast) for the decorator functions are rather confusing since, for example, create is actually initializing the particle (and creating the decorator is just a side effect and there are many other ways to create a decorator). I would propose that they change to Decorator::setup_particle for create since it sets up the required attributes on the particle and Decorator::decorator instead of cast, since it actually decorates the particle. While these changes would touch a lot of code, they could be easily done, both in svn and your code via sed since "::create(" is probably always for a decorator in c++ (and ".create(" in python). I would check a shell script into tools to aid the update. Comments? Better names?

1 0

close pairs finders and custom radius
by Daniel Russel 05 Aug '09

05 Aug '09

Having the close pairs finder support a variable radius key makes them many times (5x or so) slower than they would be if they always just used the default radius key. I propose to switch to always using XYZR::get_default_radius_key(). Objections?

2 1

Incremental scoring
by Daniel Russel 05 Aug '09

05 Aug '09

There has been some interest is supporting more efficient evaluation of the score after a small number of particles have changed. There are a number of different ways of supporting this. There are a number of challenges which have to be met by such a new scoring scheme - we don't want to have to change existing restraints to make them correct - the derivatives of particles which did not change themselves might change - we don't want to make regular evaluation less efficient - somehow have to handle combinatorial changes (such as the set of nearby particles changing) One solution would be to - each particle stores copies of all its attributes when it is modified for the first time each optimization step - a restraint can ask a particle to swap in its old values, evaluate with those, then restored the new values and evaluate with those to get the difference. This swapping of values could be made very efficient - the nonbonded list would need to add all pairs that were just removed back to the non-bonded list to make sure that they are properly subtracted off - all the dirty bits are cleared after evaluation finishes - existing restraints are all correct, they just are not necessarily as efficient as possible. Who would find fast incremental evaluations useful? What are expected scenarios? Import parts of the scenario are how many particles would change each step and what sort of restraints would be used.

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev August 2009