IMP-dev January 2011

imp-dev@salilab.org

6 participants
13 discussions

IMP-dev meeting next Tuesday
by Daniel Russel 12 Jan '11

12 Jan '11

Let's talk about providing a simple communication layer for not-entirely independent optimization runs. The general idea is to provide some class that provides a very minimal set of functionality that is sufficient to implement replica exchange and such methods. The class would be something like class JobManager { unsigned int get_number_of_jobs(); unsigned int get_my_job_number(); void publish_particles(int to_job, ParticlesTemp); void receive_particles(int from_job, ParticlesTemp); }; Implementation could be provided via files or MPI as needed. So we need to make sure we know enough about cluster jobs management to make sure things are feasible and sufficient (Ben) and what exactly is needed for replica exchange (Yannick). For other people, what other types of optimization protocols are worth thinking about? Tuesday at 1pm.

1 0

recently in IMP
by Daniel Russel 07 Jan '11

07 Jan '11

- modules can now be built externally to the \imp svn in addition to applications and biological systems. To do so, create a directory with your module in a subdir containing links to the \imp SConscript file and scons_tools and a config.py that has information needed to run \imp (eg an appropriate \c pythonpath, \c ldpath). - removed IMP::algebra::GridD::get_index(VectorD) as it wasn't very safe (in that vectors coordinates can get rounded between the IMP::algebra::GridD::get_has_index() and IMP::algebra::GridD::get_index() calls. Use IMP::algebra::GridD::get_nearest_index() or IMP::algebra::GridD::get_extended_index() or IMP::algebra::GridD::operator[]() instead. - renamed IMP::domino::ParticleStatesTable::get_particles() to IMP::domino::ParticleStatesTable::get_subset() as it is more useful to be able to get the subset containing all the particles. - rename IMP::restrainer::Restraint::print_all_restraints() to IMP::restrainer::Restraint::show_all_restraints() to be consistent with the rest of \imp. - renamed IMP::atom::get_conect_record_string() to IMP::atom::get_pdb_conect_record_string() to make clearer what it is. - class and method names are now spell checked. Add missing words to spelling_exceptions in the module test call. - the plural names (eg IMP.Particles()) have been removed from the python side as they are just python lists. - biological systems can now include internal modules. These provide a conventient place to put application specific C++ and python code. See the example system for more info. - IMP_VALUES() now includes IMP_OUTPUT_OPERATOR() so you no longer need two namespace macros for each value. - the function IMP::core::Harmonic::k_from_standard_deviation was renamed to IMP::core::Harmonic::get_k_from_standard_deviation() to conform to the standards. - the IMP::atom::PDBSelector and IMP::atom::Mol2Selector became IMP::Object classes. All this means is that they need to be created with \c new in C++ code. It also means that one is no longer prohibited from storing them (not that there is much use in doing that). - the standards tests have been improved to test more useful aspects. Now class and function names are checked some as well as all modules have the checks for show and plural types. The error messages should explain how to fix things. - IMP::core::RigidBody::lazy_set_reference_frame() was renamed to IMP::core::RigidBody::set_reference_frame_lazy() to fit with the standards better. - the transform based methods on referene frame which have been deprecated for a while were removed - the hierarchy visiting and searching functions have been renamed to better fit the \imp naming scheme as we don't expect they were used outside of the \imp source. - IMP::atom::NonhydrogenMol2Selector was renamed IMP::atom::NonHydrogenMol2Selector to be consistent with the PDB version

1 0

imp versioning
by Daniel Russel 06 Jan '11

06 Jan '11

It seems to me it might make sense to drop the idea of having releases with conventional version numbers (eg 1.0, 1.1) and simply use the svn version numbers for everything (releases as well as svn checkouts). Then we would have periodic releases which would be listed on the downloads page (along with their dates). The advantages are - only one series of version numbers for svn copies (which is what is mostly used) and releases - only one set of checks for versions are needed to use both the svn copy and the releases (eg if you want to change how your program works before and after some functionality changes) - the version numbers are maintained automatically and are very meaningful (eg if the versions are the same, then the code is the same) - different modules have different versions is quite natural - people creating modules don't have to think about versioning (assuming they use svn) - given a version number, there is one, uniform, way of getting it Disadvantages: - the version numbers don't exactly roll off the tongue (eg the kernel is 8016) - it isn't obvious what version of a module goes with what version of another module (but this isn't obvious in general, only for modules that are released as part of IMP and when a release version is used). Thoughts?

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev January 2011