- IMP-dev - salilab.org

requiring a real boost install
by Daniel Russel 26 Feb '10

26 Feb '10

I think it probably makes sense to require a real boost install to build IMP since - Dina's application uses program-options - I use file system a bit in kernel and it would make things much simpler (and, perhaps, more reliable on windows), not to have to work around its absence if it is not there - it would simplify various scripts - it is, in general, easier to get a full install of boost than a headers only one (all normal platforms have some variant of rpm, mac ports, the windows installer etc). We are telling mac people to install mac ports as it is. Comments?

2 3

IMP-dev meeting
by Daniel Russel 22 Feb '10

22 Feb '10

Let's move the imp-dev meeting to Wednesday since several people are likely to want to go to the bps meeting tomorrow and we have to be around for the visitor anyway. I propose 11am, let me know if you have an issue. Also, Keren wanted me to remind you that the plan is to ship all code that is currently in the SVN repository.

1 0

last week in IMP
by Daniel Russel 22 Feb '10

22 Feb '10

\par Week of Feb 14, 2010 - The IMP::atom::Bond types were rearranged to reconcile the protein-centric classification with ligand support. - IMP::atom::Atom no longer has charge since we have IMP::atom::Charged. - IMP::atom::read_mol2() and IMP::atom::write_mol2() were added - IMP::atom::Selector and descendents renamed to IMP::atom::PDBSelector since we will soon have Mol2Selectors. In addition, the IMP::atom::IgnoreAlteriativesSelector is now IMP::atom::NonAlternativeSelector to keep the name positive, like the others. In the \imp body, all instances of the string Selector were for PDBSelectors and so sed was safe to use. - IMP::atom::read_pdb() lost the "ignore_alternatives" argument. Instead, all of the provided selectors, other than IMP::atom::AllSelector ignore alternatives internally. Code that uses the IMP::atom::AllSelector should probably change to the IMP::atom::NonAlternativeSelector instead of the IMP::atom::AllPDBSelector (since that truly is all). - IMP::example renamed (from examples) due to various internal scripts getting confused. - The IMP_USAGE_CHECK() macro lost the (unused) third argument.

1 0

Two and half weeks until D-day
by Daniel Russel 18 Feb '10

18 Feb '10

The IMP release date is in just over two and a half weeks, so it is time to start wrapping things up. I would propose we schedule things as follows: Feb 26, last day for new functionality/cleanups. Only bug fixes and documentation changes would be allowed after this date. The things I know of that need to/or are desired to happen before this are - addition of bond angle and torsion angle force field generating functions - some cleanup of the saxs module March 1, beta release. We will declare a beta release and everyone should download it, build it, and, above all, make sure that all their existing code not in SVN works with it. In order to do this, it would be best to make sure that you update to svn head some time between now and then. Only cleanups changes to documentation and urgent bug fixes would be allowed after this time and before the release. The documentation projects that I know of are - cleanup of the introduction with more pictures and things - documentation/examples for domino - documentation/examples for multifit We then have a week to test things, read over all the documentation, try a few more platforms platforms (if we can find them, Ben has most of what we have covered pretty well). March 8, it goes on the web. March 10, Andrej raves about it. Does the schedule make sense? Does anyone need help with finishing things up in time? Anyone have any bugs to report that are not in the bugtracker? I would like help with the following - proofreading/comments on the introduction/developers guide. I would appreciate it if everyone would take at least half an hour or so and read through them at some point over the next week and a half - proposals for more examples. Anything you can think of that would either be of general interest or you found yourself doing multiple times. - if anyone has a windows machine I could borrow at some point, it would be nice to test things on a real machine. Otherwise, I'll rig something up with virtual box. Things are coming together, I think :-)

1 0

Last week in IMP
by Daniel Russel 15 Feb '10

15 Feb '10

- The model io code as moved into the kernel so it is now IMP::write_model() and IMP::read_model() - Remove the version_info argument from the implementation macros. Instead, just pick up the module version info automatically. - Add a function Object::get_type_name() and Object::get_module() to get the respective bits of information about each object. - Change Object::show() to be a non-virtual wrapper which prints the object name and other info before passing control off to Object::do_show(). - The containers were moved to IMP.container. See that module page for a full list of what moved. In the process, the backwards compatability functions were removed from IMP::container::PairsRestraint and kin. - IMP.atom.create_protein() now returns the created protein - the simplify functions have been moved from IMP.helper. They are now IMP.atom.create_simplified_along_backbone(). - IMP.helper.clone() has been renamed to IMP.atom.create_clone() - IMP.misc.ConnectingPairContainer has been moved to IMP.core.ConnectingPairContainer - The locations for pixels in IMP::em::DensityMap have been moved to the center of the corresponding voxel from the lower left corner. - IMP::em::get_transformed(), IMP::em::get_resampled() and IMP::em::get_density() have been added. - The documentation has been majorly cleaned up and simplified. Please look around and see if you like it. There are now two main pages, the introduction and the developers guide, rather than the previous plethora of pages. - IMP::algebra::Cone3D::get_bounding_sphere() has been removed since it was not of general use, not returning the bounding sphere you would expect and was trivial to implement. - IMP::algebra::projection() was removed since it didn't actually project onto the segment and the name didn't follow the normal conventions. And it wasn't used. - Most geometry now has namespace methods IMP::algebra::get_bounding_box(), IMP::algebra::get_surface_area(), IMP::algebra::get_volume().

1 0

Moving container-related code to its own module
by Daniel Russel 12 Feb '10

12 Feb '10

I'm proposing moving the container-related code out of core into their own module. This is something I'd thought about when I first implemented them, but had decided not to, without any strong reason. The reasons for wanting to do this now are: - they form a well defined collection of functionality that can be best explained together - the list of functionality in core is very long and hard to one's head around - core is huge, takes forever to compile Affected classes would be List*Container, *ContainerSet, AllPairContainer and kin and ClosePairContainer and kin. I think few people use the classes directly currently, other than to create ListSingletonContainers, so there would not be too many changes. Thoughts? Objections?

3 2

Re: [IMP-dev] [IMP-commits] r4751 - trunk/modules/restrainer/examples
by Elina Tjioe 10 Feb '10

10 Feb '10

Ben, I noticed that during the build time we are running not only unit tests but also examples. This causes problems with paths to input data files and forces each example to use complicated logic to calculate paths. I believe it would be nice if examples were as simple as possible, since they are meant to be read by the users. Would it be a good idea to modify the build process to run examples from their respective directories? This way all examples can use the relative paths and if a user wishes to run an example, he/she can just cd to the example directory and run it directly from there. Thx, Elina On Wed, Feb 10, 2010 at 8:37 AM, Notification of IMP commits < imp-commits(a)salilab.org> wrote: > Author: ben(a)SALILAB.ORG > Date: 2010-02-10 08:37:04 -0800 (Wed, 10 Feb 2010) > New Revision: 4751 > > Modified: > trunk/modules/restrainer/examples/basic_setup.py > Log: > Use get_example_path() to find inputs. > > > Modified: trunk/modules/restrainer/examples/basic_setup.py > =================================================================== > --- trunk/modules/restrainer/examples/basic_setup.py 2010-02-10 16:07:22 > UTC (rev 4750) > +++ trunk/modules/restrainer/examples/basic_setup.py 2010-02-10 16:37:04 > UTC (rev 4751) > @@ -4,11 +4,13 @@ > import IMP.restrainer > > # Load molecular hierarchy definition > -RepParser = > IMP.restrainer.XMLRepresentation('input/eg1_representation.xml') > +RepParser = IMP.restrainer.XMLRepresentation( > + > IMP.restrainer.get_example_path('input/eg1_representation.xml')) > representation = RepParser.run() > > # Load the restraint set > -RestraintParser = IMP.restrainer.XMLRestraint('input/eg1_restraint.xml') > +RestraintParser = IMP.restrainer.XMLRestraint( > + > IMP.restrainer.get_example_path('input/eg1_restraint.xml')) > restraint = RestraintParser.run() > > # Place representation into IMP model > > _______________________________________________ > IMP-commits mailing list > IMP-commits(a)salilab.org > https://salilab.org/mailman/listinfo/imp-commits >

3 6

Fwd: FixedZYZ fixed_zyz_from_rotation
by Javier Ángel Velázquez Muriel 31 Jan '10

31 Jan '10

2010/1/30 Daniel Russel <drussel(a)gmail.com>: > Check that the choice of Euler angles isn't singular near that point (each > choice of Euler angles has a place where it is singular, meaning very > different Euler angle values produce almost the same rotation). Yes, I think that is what is happening here, but I don't know how to repair it. How does the > instability manifest itself. When psi is 0, then sin(psi) = 0 and you're dividing by it. Needs a check, that is what I did. Does it help? > > I'll try to look more into it later. > > > On Jan 29, 2010, at 8:46 PM, Javier Ángel Velázquez Muriel > <javi(a)salilab.org> wrote: > >> That function enters into numerical instability when >> sin_tilt_sin_psi==0, which produces psi ==0. I've tried to fixe it, >> and i think is correct, but now the code throws the exception. The >> input and output are "apart". Can anybody help me to fix it? Anything >> that I missed? >> >> double psi= std::atan2(sin_tilt_sin_psi, cos_psi_sin_tilt); >> if(almost_equal(sin_tilt_sin_psi,0,1e-6)) { >> double sin_tilt= 0; >> double tilt= std::atan2(sin_tilt, cos_tilt); >> } else { >> double sin_tilt= sin_tilt_sin_psi/std::sin(psi); >> double tilt= std::atan2(sin_tilt, cos_tilt); >> } >> // double cos_rot= cos_rot_sin_tilt/sin_tilt; >> // double sin_rot= sin_rot_sin_tilt/sin_tilt; >> // double rot= std::atan2(sin_rot, cos_rot); >> double rot= std::atan2(sin_rot, cos_rot); >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev(a)salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev(a)salilab.org > https://salilab.org/mailman/listinfo/imp-dev >

2 1

FixedZYZ fixed_zyz_from_rotation
by Javier Ángel Velázquez Muriel 30 Jan '10

30 Jan '10

That function enters into numerical instability when sin_tilt_sin_psi==0, which produces psi ==0. I've tried to fixe it, and i think is correct, but now the code throws the exception. The input and output are "apart". Can anybody help me to fix it? Anything that I missed? double psi= std::atan2(sin_tilt_sin_psi, cos_psi_sin_tilt); if(almost_equal(sin_tilt_sin_psi,0,1e-6)) { double sin_tilt= 0; double tilt= std::atan2(sin_tilt, cos_tilt); } else { double sin_tilt= sin_tilt_sin_psi/std::sin(psi); double tilt= std::atan2(sin_tilt, cos_tilt); } // double cos_rot= cos_rot_sin_tilt/sin_tilt; // double sin_rot= sin_rot_sin_tilt/sin_tilt; // double rot= std::atan2(sin_rot, cos_rot); double rot= std::atan2(sin_rot, cos_rot);

3 2

No imp-dev meeting today
by Daniel Russel 26 Jan '10

26 Jan '10

1 0