IMP-dev January 2009

imp-dev@salilab.org

11 participants
37 discussions

EM issues
by Daniel Russel 28 Jan '09

28 Jan '09

I can't build EM and so was poking through the code. - EM{noise, resample, etc} should be just be {noise, resample, etc} to be consistent with other names in other modules and the core (all access are already prefixed with via the paths and namespaces). - in general it is less error prone to use an enum for modes rather than a string (in noise, for example) as they get documented better and can only exist in correct values - calling the arguments to add_noise op1 and op2 is horrible. They should have descriptive names. - given we have a rotation class, "project" should use that rather than its own convention for defining rotations - in general we avoid passing return return values as arguments ("project"). At the very least, if you do that you need to make sure that the non-return arguments are const refs, rather than refs and the last arguments.

1 0

Re: [IMP-dev] [IMP-commits] r1297 - trunk/modules/algebra/include
by Daniel Russel 28 Jan '09

28 Jan '09

It also means that when someone creates a default Transformation3D, you don't know if they want the identity transform or just will initialize it later. And it's not symmetric with the Vector3D and the Rotation3D. On Jan 27, 2009, at 10:16 PM, Notification of IMP commits wrote: > Author: kerenl(a)SALILAB.ORG > Date: 2009-01-27 22:16:23 -0800 (Tue, 27 Jan 2009) > New Revision: 1297 > > Modified: > trunk/modules/algebra/include/Transformation3D.h > Log: > change to default constrator to initilize the identity transformation > > Modified: trunk/modules/algebra/include/Transformation3D.h > =================================================================== > --- trunk/modules/algebra/include/Transformation3D.h 2009-01-27 > 22:26:43 UTC (rev 1296) > +++ trunk/modules/algebra/include/Transformation3D.h 2009-01-28 > 06:16:23 UTC (rev 1297) > @@ -25,6 +25,8 @@ > typedef Transformation3D This; > //! construct and invalid transformation > Transformation3D(){ > + trans_=Vector3D(0.0,0.0,0.0); > + rot_ = identity_rotation(); > } > /** basic constructor*/ > Transformation3D(const Rotation3D& r, const Vector3D& t) > > _______________________________________________ > IMP-commits mailing list > IMP-commits(a)salilab.org > https://salilab.org/mailman/listinfo/imp-commits

3 6

Re: [IMP-dev] [IMP-commits] r1297 - trunk/modules/algebra/include
by Daniel Russel 27 Jan '09

27 Jan '09

I really don't like having the default constructor have some meaning like that since you have no way of knowing what it is doing without reading the documentation. Much better to have a method produce the identity transform. On Jan 27, 2009, at 10:16 PM, Notification of IMP commits wrote: > Author: kerenl(a)SALILAB.ORG > Date: 2009-01-27 22:16:23 -0800 (Tue, 27 Jan 2009) > New Revision: 1297 > > Modified: > trunk/modules/algebra/include/Transformation3D.h > Log: > change to default constrator to initilize the identity transformation > > Modified: trunk/modules/algebra/include/Transformation3D.h > =================================================================== > --- trunk/modules/algebra/include/Transformation3D.h 2009-01-27 > 22:26:43 UTC (rev 1296) > +++ trunk/modules/algebra/include/Transformation3D.h 2009-01-28 > 06:16:23 UTC (rev 1297) > @@ -25,6 +25,8 @@ > typedef Transformation3D This; > //! construct and invalid transformation > Transformation3D(){ > + trans_=Vector3D(0.0,0.0,0.0); > + rot_ = identity_rotation(); > } > /** basic constructor*/ > Transformation3D(const Rotation3D& r, const Vector3D& t) > > _______________________________________________ > IMP-commits mailing list > IMP-commits(a)salilab.org > https://salilab.org/mailman/listinfo/imp-commits

1 0

modules question
by Keren Lasker 27 Jan '09

27 Jan '09

hi, One of the functions defined in domino::TransformationMappedDiscreteSet is: algebra::Transformation3D get_trans(Particle *p_target, long state_ind) const; my domino.i includes Algebra.h, and still I get: modules/domino/pyext/domino_wrap.cc: In function 'PyObject* _wrap_TransformationMappedDiscreteSet_get_trans(PyObject*, PyObject*)': modules/domino/pyext/domino_wrap.cc:11592: error: 'algebra' has not been declared modules/domino/pyext/domino_wrap.cc:11592: error: expected `;' before 'result' modules/domino/pyext/domino_wrap.cc:11612: error: 'result' was not declared in this scope modules/domino/pyext/domino_wrap.cc:11621: error: expected type- specifier before 'algebra' modules/domino/pyext/domino_wrap.cc:11621: error: expected `)' before 'algebra' modules/domino/pyext/domino_wrap.cc:11621: error: expected `)' before ';' token (which corresponds to the return value of get_trans) should I add something else to domino.i to make it work? thanks, Keren.

2 2

Restraints and Hierarchy
by Keren Lasker 27 Jan '09

27 Jan '09

hi, Lets say I have two proteins A and B and I want to calculate a distance restraint between them. Usually it would be preferable to calculate the distance restraint between their centroids. However, their centroids are derived from the positions of their atoms. So - even if I calculate the centroids of the protein particle and add XYZ attributes, the calculating of the distance restraint will be true for the first time - but the state of the XYZ attributes of the protein particles should be updated according to the atom positions. Has anyway come across this issue before? thanks, Keren.

3 5

Linear algebra
by Daniel Russel 23 Jan '09

23 Jan '09

I'd like to compute a SVD in IMP, so we need to revisit the question of linear algebra packages. The two main options as I see it are: 1) using some big blas implementation through boost.ublas's bindings. The advantages are that operations will then be really fast. The disadvantages are that is is a bit complicated and introduces an (easy, since basically all systems have some blas library installed) external dependency. 2) use TNT. The advantages are that is is header only and has a nice license so we can hide it away internally. On the flip side, we can't count on it being installed so we have to hide it away internally, and it isn't the best implementation of things. It is also a bit limited (but SVD can solve all problems :-). Unless there are counter proposals, I'll stick a copy of TNT in somewhere.

4 14

memory leakage in IMP
by Friedrich Foerster 23 Jan '09

23 Jan '09

hi all, somehow i keep on stealing my computer memory when running imp from python. either my awkward programming style or a bug in imp/swig steals the memory from my system. attached is an example illustrating the problem. if you monitor the memory usage, you'll see the consumed memory gradually increasing - although the same variable is used throughout the loop. thus, apparently new memory is constantly allocated and i have no clue what happened to the old one. needless to say the code could eventually kills every system given the loop is large enough. any help on the whereabouts of my memory would be greatly appreciated... tx frido

3 4

"python interface" platform
by Daniel Russel 23 Jan '09

23 Jan '09

In the nightly build, there is a platform called "Python interface". What is it?

2 1

New IMP permissions and branches
by Ben Webb 23 Jan '09

23 Jan '09

Further to last Friday's meeting, I have updated the permissions on the IMP Subversion repository, and created some new branches, as detailed below. Note: the IMP SVN trunk should still be treated as "stable". Code checked in should compile and pass its test cases, as is currently the case. Breakage of the nightly builds needs to be fixed as soon as possible so that people can develop with the trunk without running into problems with code from others. The policies and guidelines at https://salilab.org/imp/doc/doxygen/devguide.html are largely unchanged. In particular, API changes to modules should still be announced on imp-dev (ideally when the interface is designed, before the code itself is written). API changes to the kernel also need to be announced on imp-dev before they are implemented; only if nobody objects within two working days to the change can it be applied. I have also created some new branches: - branches/stable is updated from trunk whenever the nightly builds pass. Thus, people like Frido can use branches/stable and do an 'svn up' confident that it works (at least for us). For example, 'svn co https://svn.salilab.org/imp/branches/stable' will check out the stable branch, while 'svn switch https://svn.salilab.org/imp/branches/stable .' run from within an existing checkout of the IMP trunk will switch it to the stable branch. Once checked out or switched, the stable branch works in just the same way as the trunk - you just can't make patches to it (development takes place on the trunk). - branches/salilab/ is a directory under which people can create their own branches for not yet published stuff that we cannot make public outside the lab yet. - branches/testing/ is a directory under which short-lived branches for development/testing can be created. Code need not compile or work. Such branches should be deleted or merged back into the trunk once the code stabilizes. testing branches are not built by the nightly builds, of course. The default access permissions now are that everybody can read everything in IMP, while those in a select 'imp-writers' group can write. Thus the imp-writers people can also create new branches under branches/salilab or branches/testing if they so desire. (I recommend that you do not create a branch unless you really need to, though - it's much easier to keep up with others if you work in the trunk.) Exceptions: - those outside the Sali lab cannot read or write branches/salilab/. - branches/stable is read only - development must occur in the trunk. - modules are always writable by their owners, even if they are not in the imp-writers group. - everybody can write into trunk/patches/, as is currently the case. imp-writers are those in the Sali lab that have asked for write access. To be added to this group, I would typically ask you to make your first few contributions via the 'old' mechanism (write a patch and put it in the patches directory) until you get the hang of how things work. Ben -- ben(a)salilab.org http://salilab.org/~ben/ "It is a capital mistake to theorize before one has data." - Sir Arthur Conan Doyle

1 0

deprecated classes
by Daniel Russel 20 Jan '09

20 Jan '09

There are a number of classes in IMP.core which have been marked as deprecated for a while. I would be good to get rid of them entirely before the first public release. I propose that after the first marked stable version (a concept which will be explained in a forthcoming email from Ben), I remove them from SVN. So please check your code to make sure you don't use them and if you do, start migrating to the replacement classes. You can find a list of such classes at <https://salilab.org/imp/doc/doxygen/deprecated.html> and you code should spit out warning messages whenever you create an instance of such a class.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev January 2009