- IMP-dev - salilab.org

Q) How to correlate atoms and residue in IMP molecular hierarchy?
by Seung Joong Kim 07 Jan '09

07 Jan '09

Hi all, This can be a very simple question, but I'm just wondering how to correlate atoms and a residue in IMP molecular hierarchy. First of all, I get "IMP::core::MolecularHierarchyDecorator mp" by calling read_pdb function defined in IMP modeller module. It simply reads contents of a pdb file and generates the molecular hierarchy. mp = IMP.modeller.read_pdb('single_protein.pdb', m) Then, I load particles by calling "molecular_hierarchy_get_by_type" function as follows. ps_ = IMP::core::molecular_hierarchy_get_by_type(mp_, IMP::core::MolecularHierarchyDecorator::ATOM); IMP::core::AtomDecorator ad = IMP::core::AtomDecorator::cast(ps_[i]); IMP::core::AtomType at = ad.get_type() residues = IMP.core.molecular_hierarchy_get_by_type(mp, IMP.core.MolecularHierarchyDecorator.RESIDUE); IMP::core::ResidueDecorator rd = IMP::core::ResidueDecorator::cast(residues_[i]); IMP::core::ResidueType rt = rd.get_type(); By doing this, I get only independent particle arrays of atom and residue, without any relation between them. What I want to know is a piece of linked information between atom index and residue index, such that a Nitrogen atom (atom index 458) is positioned at a LYS residue (residue index 56). ATOM 458 N LYS 56 38.397 16.302 23.700 1.00 18.45 N Is there any simple function defined in MolecularHierarchyDecorator class for this purpose? (Input : atom index & Output : residue index, and vice versa.) Or is there any other simple way to do this? Thanks a lot! Seung Joong Kim

2 1

Re: [IMP-dev] [IMP-commits] r1102 - in trunk/kernel: doc/patch include pyext/IMP src test/particles
by Daniel Russel 05 Jan '09

05 Jan '09

This patch needs the following added to the appropriate place to not break memory management. + %pythonprepend Particle::Particle %{ + if len(args) >0: self.thisown=False + %} Probably got lost somewhere in the patch process. On Jan 5, 2009, at 11:43 AM, Notification of IMP commits wrote: > Author: ben(a)SALILAB.ORG > Date: 2009-01-05 11:43:25 -0800 (Mon, 05 Jan 2009) > New Revision: 1102 > > Removed: > trunk/kernel/doc/patch/particle_model.patch > trunk/kernel/doc/patch/particle_model.readme > Modified: > trunk/kernel/include/Particle.h > trunk/kernel/pyext/IMP/test.py > trunk/kernel/src/Particle.cpp > trunk/kernel/test/particles/test_refcount.py > Log: > Patch from Daniel, with minor cleanup by me: add a constructor to > Particle to > take a Model, and change a few tests to use this constructor. > > > Modified: trunk/kernel/include/Particle.h > =================================================================== > --- trunk/kernel/include/Particle.h 2008-12-31 00:40:19 UTC (rev 1101) > +++ trunk/kernel/include/Particle.h 2009-01-05 19:43:25 UTC (rev 1102) > @@ -96,8 +96,9 @@ > > public: > > + //! Construct a particle and add it to the Model > + Particle(Model *m); > > - > Particle(); > ~Particle(); > > > Modified: trunk/kernel/pyext/IMP/test.py > =================================================================== > --- trunk/kernel/pyext/IMP/test.py 2008-12-31 00:40:19 UTC (rev 1101) > +++ trunk/kernel/pyext/IMP/test.py 2009-01-05 19:43:25 UTC (rev 1102) > @@ -34,8 +34,7 @@ > def create_point_particle(self, model, x, y, z): > """Make a particle with optimizable x, y and z attributes, and > add it to the model.""" > - p = IMP.Particle() > - model.add_particle(p) > + p = IMP.Particle(model) > p.add_attribute(IMP.FloatKey("x"), x, True) > p.add_attribute(IMP.FloatKey("y"), y, True) > p.add_attribute(IMP.FloatKey("z"), z, True) > > Modified: trunk/kernel/src/Particle.cpp > =================================================================== > --- trunk/kernel/src/Particle.cpp 2008-12-31 00:40:19 UTC (rev 1101) > +++ trunk/kernel/src/Particle.cpp 2009-01-05 19:43:25 UTC (rev 1102) > @@ -11,6 +11,13 @@ > > IMP_BEGIN_NAMESPACE > > +Particle::Particle(Model *m) > +{ > + is_active_ = true; > + m->add_particle(this); > +} > + > + > Particle::Particle() > { > is_active_ = true; > > Modified: trunk/kernel/test/particles/test_refcount.py > =================================================================== > --- trunk/kernel/test/particles/test_refcount.py 2008-12-31 00:40:19 > UTC (rev 1101) > +++ trunk/kernel/test/particles/test_refcount.py 2009-01-05 19:43:25 > UTC (rev 1102) > @@ -34,8 +34,7 @@ > self._check_number(0) > > m= IMP.Model() > - p= IMP.Particle() > - m.add_particle(p) > + p= IMP.Particle(m) > self._check_number(1) > > p=1 > @@ -47,8 +46,8 @@ > """Check that ref counting works with removing particles""" > self._check_number(0) > m= IMP.Model() > - p= IMP.Particle() > - pi= m.add_particle(p) > + p= IMP.Particle(m) > + pi= p.get_index() > self._check_number(1) > m.remove_particle(pi) > self._check_number(1) > @@ -86,10 +85,10 @@ > self._check_number(0) > m= IMP.Model() > print 7 > - p= IMP.Particle() > + p= IMP.Particle(m) > print p > print 8 > - pi= m.add_particle(p) > + pi= p.get_index() > print 9 > p=None > self._check_number(1) > @@ -141,8 +140,8 @@ > """Check that removed particles are skipped""" > print "skipped" > m= IMP.Model() > - p= IMP.Particle() > - pi= m.add_particle(p) > + p= IMP.Particle(m) > + pi= p.get_index() > ps= m.get_particles() > self.assertEqual(len(ps), 1, "Should only be 1 particle") > m.remove_particle(pi) > > _______________________________________________ > IMP-commits mailing list > IMP-commits(a)salilab.org > https://salilab.org/mailman/listinfo/imp-commits

1 0

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