IMP-dev December 2008

imp-dev@salilab.org

8 participants
38 discussions

Index objects
by Daniel Russel 16 Jan '09

16 Jan '09

After talking with Dina, I realized that there isn't really any circumstance under which it makes sense to use the ParticleIndex (or RestraintIndex) objects as one is always better off storing the Particle pointers. I propose removing the indexes and replacing the storage with a boost intrusive list. This will make it clear to new people that they should not be using the Indexes and make various code much simpler (since the range will always be full, even after deletions). Likewise the ParticleIterators in model probably should be hidden so people aren't tempted to use them, but doing this is complicated by the macros being reused in many places and so is not as trivial a change.

2 1

ambiguous restraints
by Friedrich Foerster 29 Dec '08

29 Dec '08

hi there, is there any example for generating ambiguous restraints in imp? i want to deal with a 'frank classic': multiple copies of a specific protein exist in an assembly and only one instance interacts with another protein (the one that is closer to its putative partner). i guess npc people need it every day. thanks frido -- Friedrich Foerster Max-Planck Institut fuer Biochemie Am Klopferspitz 18 D-82152 Martinsried Tel: +49 89 8578 2651 Fax: +49 89 8578 2641 foerster(a)biochem.mpg.de www.tomotronic.org

2 8

Simplified SConscripts in core, misc
by Daniel Russel 22 Dec '08

22 Dec '08

I've been using a simplified set of SConscripts for the search module which simply uses all .h's in include/ and include/*/ and all .cpps in src and src/*/ rather than just a specified list. The removes the need to run the make-sconscript script when you add headers. Unless anyone objects I'll change the core scripts to do this. And then there will be one less thing to keep in sync :-)

3 4

Re: [IMP-dev] [IMP-commits] r1054 - trunk/kernel/pyext/IMP
by Daniel Russel 22 Dec '08

22 Dec '08

Overall I don't really see the benefit of such a feature unless it is going to be used to make it so you can run tests from any cwd (since the correct one is nonobvious) or to separate the test data from the tests so we dont have 4 copies of single_protein.pdb around. And in either of those cases the current directory is a bad default as you have to be elsewhere for almost any other operation (and the commit log messages was poor). Also, what happened to posting changes to how things work on imp-dev for comment? On Dec 18, 2008, at 6:58 PM, Notification of IMP commits <imp-commits(a)salilab.org > wrote: > Author: ben(a)SALILAB.ORG > Date: 2008-12-18 18:58:41 -0800 (Thu, 18 Dec 2008) > New Revision: 1054 > > Modified: > trunk/kernel/pyext/IMP/test.py > Log: > Default to current directory if TEST_DIRECTORY is not set. > > > Modified: trunk/kernel/pyext/IMP/test.py > =================================================================== > --- trunk/kernel/pyext/IMP/test.py 2008-12-18 22:28:10 UTC (rev > 1053) > +++ trunk/kernel/pyext/IMP/test.py 2008-12-19 02:58:41 UTC (rev > 1054) > @@ -18,7 +18,9 @@ > > def get_test_file(self, filename): > """Get the full name of a file in the top-level test > directory.""" > - path = os.environ['TEST_DIRECTORY'] > + # If individual tests are run manually, assume they are in > + # the current directory: > + path = os.environ.get('TEST_DIRECTORY', '.') > return os.path.join(path, filename) > > def assertInTolerance(self, num1, num2, tolerance, msg=None): > > _______________________________________________ > IMP-commits mailing list > IMP-commits(a)salilab.org > https://salilab.org/mailman/listinfo/imp-commits

2 4

particle creation
by Daniel Russel 22 Dec '08

22 Dec '08

Since every call of p=IMP.Particle() is immediately followed by m.add_particle(p) (and at this point there is no way to make it so that a particle could be in multiple models) I'd suggest that we add a constructor of Particle that takes a model allowing everyone to save a line here and there. The usage is so asymetric between particles and restraints and things that I don't think our original rationale for having the two calls be separate holds. We can leave the old one for backward compatibility (but hide it in the documentation and examples).

2 1

Re: [IMP-dev] [IMP-commits] r1073 - in trunk/kernel: include pyext test/misc
by Daniel Russel 22 Dec '08

22 Dec '08

Other places we call such methods "distance". I'm not sure we are entirely consistent everywhere on having get or not in non-member functions, but we should be. Personally, I prefer not having the "get" when it is not a member (since there is no where to get it from) but could go either way. Notification of IMP commits wrote: > Author: ben(a)SALILAB.ORG > Date: 2008-12-22 13:29:36 -0800 (Mon, 22 Dec 2008) > New Revision: 1073 > > Modified: > trunk/kernel/include/VectorD.h > trunk/kernel/pyext/Vector3D.i > trunk/kernel/test/misc/test_vector3d.py > Log: > Patch from Dina, with minor cleanup and additions by me: add methods to > calculate distance and squared distance between two "pointlike" vectors. > > > Modified: trunk/kernel/include/VectorD.h > =================================================================== > --- trunk/kernel/include/VectorD.h 2008-12-22 21:08:32 UTC (rev 1072) > +++ trunk/kernel/include/VectorD.h 2008-12-22 21:29:36 UTC (rev 1073) > @@ -339,7 +339,24 @@ > } > > > +//! compute the squared distance between two vectors > template <unsigned int D> > +Float get_squared_distance(const VectorD<D> &v1, const VectorD<D> &v2) { > + Float d, s = 0; > + for (unsigned int i=0; i< D; ++i) { > + d = v1[i] - v2[i]; > + s += d*d; > + } > + return s; > +} > + > +//! compute the distance between two vectors > +template <unsigned int D> > +Float get_distance(const VectorD<D> &v1, const VectorD<D> &v2) { > + return std::sqrt(get_squared_distance(v1, v2)); > +} > + > +template <unsigned int D> > struct SpacesIO > { > const VectorD<D> &v_; > > Modified: trunk/kernel/pyext/Vector3D.i > =================================================================== > --- trunk/kernel/pyext/Vector3D.i 2008-12-22 21:08:32 UTC (rev 1072) > +++ trunk/kernel/pyext/Vector3D.i 2008-12-22 21:29:36 UTC (rev 1073) > @@ -56,4 +56,6 @@ > %template(random_vector_on_unit_sphere) random_vector_on_unit_sphere<3>; > %template(random_vector_in_unit_sphere) random_vector_in_unit_sphere<3>; > %template(random_vector_in_unit_box) random_vector_in_unit_box<3>; > -} > \ No newline at end of file > + %template(get_distance) get_distance<3>; > + %template(get_squared_distance) get_squared_distance<3>; > +} > > Modified: trunk/kernel/test/misc/test_vector3d.py > =================================================================== > --- trunk/kernel/test/misc/test_vector3d.py 2008-12-22 21:08:32 UTC (rev 1072) > +++ trunk/kernel/test/misc/test_vector3d.py 2008-12-22 21:29:36 UTC (rev 1073) > @@ -100,6 +100,14 @@ > for i in range(3): > self.assertEqual(prod[i], expected_prod[i]) > self.assertEqual(v1[i], expected_prod[i]) > + > + def test_distance(self): > + """Check distance between two vectors""" > + v1 = IMP.Vector3D(3.0, 6.0, 9.0) > + v2 = IMP.Vector3D(1.0, 2.0, 3.0) > + self.assertEqual(IMP.get_squared_distance(v1, v2), 56) > + self.assertInTolerance(IMP.get_distance(v1, v2), 7.4833, 0.01) > + > def test_generators(self): > """Check the Vector3D generators""" > # test calling since it is a bit non-trivial in SWIG > > _______________________________________________ > IMP-commits mailing list > IMP-commits(a)salilab.org > https://salilab.org/mailman/listinfo/imp-commits >

3 3

patch to the patch process
by Daniel Russel 22 Dec '08

22 Dec '08

I suggest we change the process for submitting patches to the following: - have a directory writable by everyone such as IMP/patch - to submit a patch, foo, check in trunk/patch/foo.patch and truck/ patch/foo.readme with the patch and a description, respectively - send a short email to imp-dev - when Ben commits the patch, he removes the files from SVN The advantage of this system is: - it is easy to see keep track of what patches have been submitted but not committed. - it is easy to update patches that have been submitted but not yet committed - it is easy to apply patches that have not yet been committed to your copy of IMP, so is is less problematic when patches don't get committed for a long time. - no more having to get files to your email - all the submitted patches are listed in one place for ben to see - the submitted doesn't have to manually clean how his records of the patch when Ben submits it. Anyone have improvements? I'll try out such a system with my next patch.

5 9

index structures
by Daniel Russel 20 Dec '08

20 Dec '08

There is now a patch creating a search module which currently has a class to quickly find particles which have a certain values of some given attributes. I wanted to call the module "index" but that stomped on Index.h, so it became "search" instead. The python side of things is kind of a pain as it is too hard for swig to properly parse some of the templates. One could write a cool python wrapper which delegated to the correct C++ structure internally, but I won't. There are also several other patches in kernel/doc/patch which: - document Particles - add a way to force ScoreStates to update (without having to guess a sequence number to use) - add the posted methods to create atom and residue types - add output to pairs and triplets - remove redundant documentation (although I suspect patches involving moving files are useless, but Ben hasn't responded on this) - clean up the configure scripts to make them more portable and less broken...

2 3

query particles
by Keren Lasker 19 Dec '08

19 Dec '08

hi all, Frido and I find ourselves many times need to query particles based on attribute values. Few such examples: a protein with a specific name, particles with a specific residue range. I think that it would be very useful to have something similar to SQL queries on the particles DB. Bret might had something similar implemented - but it is probably obsolete. IMP.Atom will probably need such functionality as well. has anyone took a look at that before ? thank you, Keren.

5 26

derivatives of IMP float attributes
by Friedrich Foerster 19 Dec '08

19 Dec '08

hi all, when checking the attributes of my IMP particles i discovered that all float attributes have derivative values. is there any option to switch that off? now i get derivatives for fixed parameters such as radii or mass weights, which are a mere waste of memory. a possible solution would be to distinguish attributes into variables and parameters. thanks frido -- Friedrich Foerster Max-Planck Institut fuer Biochemie Am Klopferspitz 18 D-82152 Martinsried Tel: +49 89 8578 2651 Fax: +49 89 8578 2641 foerster(a)biochem.mpg.de www.tomotronic.org

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev December 2008