IMP-dev November 2007

imp-dev@salilab.org

6 participants
11 discussions

[Fwd: PDB lib]
by Ben Webb 19 Nov '07

19 Nov '07

Forwarded to the list for reference. -------- Original Message -------- Subject: PDB lib Date: Tue, 13 Nov 2007 16:06:24 -0800 From: Daniel Russel <drussel(a)gmail.com> Reply-To: drussel(a)salilab.org To: Ben Webb <ben(a)salilab.org> References: <3682E173-8139-44FE-8BB0-C2739807D71E(a)salilab.org> <473A0947.9030501(a)salilab.org> <473A09AD.2000603(a)gmail.com> <473A31BC.1060000(a)salilab.org> > > At any rate, this PDB reader stuff needs to be discussed on imp-dev > before we proceed. For example, what's wrong with the BALL stuff you > were playing with before? BALL is dead. No activity on email list. No response to bugs. No move to actually document their newest version even though it was released a year ago. I don't think we want to tie ourselves to it. Sure we can take it to IMP dev. No one else seems to care much :-) I have looked around and asked around and couldn't find any decent PDB readers (in C or C++) which are not buried in some huge project. > Why can't we link against this PDB library, rather than > cut-and-pasting thousands of lines of code? The nice thing about it is that it is small and simple and mine so we can just ship it along with IMP and not worry about dependencies, name collisions etc. I don't want people to have to get another library from somewhere else, hence my desire to put a copy into imp svn. Soon enough the lib will make it to fedora extras (whenever the next CGAL release is) so we could potentially just use that. > Should the kernel include a PDB reader anyway? It doesn't matter if it is in the kernel or a separate lib that is brought along, especially since we are using dynamic linking (so the library can be pulled in my libimp). Everyone seems to want a PDB reader, including me so we need one somewhere. > My concerns are 1. it'll be a maintenance nightmare to fork this PDB > library, Not at all. It doesn't actually need forking other than changing #include <CGAL/PDB to #include <IMP/PDB to avoid stomping on things. I really with there were some way to parameterize such things. It was written to be self-contained, I just got sloppy with the last few changes so I had to fix those this morning). > 2. it's LGPL so we can't include it in IMP without being forced to > adopt LGPL (only link against it) Why would we want to do more than link against it? Anyway, changing the license is easy. It was initially free, I just changed the license recently because much of the rest of CGAL is LGPL. > and 3. from a brief reading, it looks like a not-very-good PDB library > anyway (hard-coded atom names - what's with that?) Well, it is either that or use strings which pushes the checks to runtime rather than compile time. Adding to an enum and recompiling is trivial (and adding a constant externally works just as well for must purposes). Checking everywhere than an object falls in a small set of allowed strings is hard (especially if you can't specify that set of strings anywhere). BALL has hardcoded atoms for that matter (just a lot more of them :-) Anyway, I am a fan of it (as I should be :-) And since our backups are rather less than I thought, the ball code got lost with the constant rechecking out of IMP.

4 9

[Fwd: Re: [Fwd: PDB lib]]
by Ben Webb 16 Nov '07

16 Nov '07

Forwarding to the list: -------- Original Message -------- Subject: Re: [IMP-dev] [Fwd: PDB lib] Date: Fri, 16 Nov 2007 12:18:04 -0800 From: Eswar Narayanan <eswar(a)salilab.org> To: Ben Webb <ben(a)salilab.org> CC: imp-dev(a)salilab.org References: <473A42F7.4060005(a)salilab.org> <473BAF19.30207(a)salilab.org> <B3063E98-E0A6-4032-A70F-CF72419F8441(a)salilab.org> <473DE358.4000203(a)salilab.org> Somebody called me an expert, so I'm compelled to reply! I must confess though that I haven't been paying attention to the discussions before this and couldn't locate the origin of this PDB thread. So I'm probably missing some critical information here - for instance, I have no clue why so much is being discussed about reading and interpreting a PDB file. Absolutely nothing in the PDB file is believable (I can give you any number of examples to prove this). So by definition, if someone claims they have the ultimate reader, I think that person should seriously consider taking astrology as a vocation. But my two cents: I think the PDB parser of Modeller is already quite good and could be made better with just a few tweaks. More than anything else, I think we completely understand where the problems are. So even if it comes to recoding it from scratch (if licensing is an issue), in the long run, it is probably much easier and faster than tinkering with someone else's code. Ben and I have already had long email conversations on some of the limitations of the Modeller implementation and at least in principle know how to fix it. And even if Ben pokes fun at it, it has withstood the test of time for close to two decades. Is there a reason you don't want to use the PDB reader from Modeller? E. On Nov 16, 2007, at 10:37 AM, Ben Webb wrote: > Daniel Russel wrote: >> I think Ben and I have a disagreement about the significance of >> picking >> a PDB reader at this point. As I see it, any PDB reading should be >> hidden behind some very general interface (I have a proposal using >> the >> MolecularHierarchyDecorator). > > Agreed. We can certainly use whichever PDB reader you're happy with in > the short term. But I have a lot of experience with reading dodgy PDB > files (although Eashwar is probably the lab expert in this regard) so > know there's a lot of corner cases to worry about, and I don't relish > fixing all of these again with a new PDB reader. And that's before we > start worrying about heterogens. > >> I picked my pdb reader since it is small and so can be stuck in the >> with >> rest of imp so that no one has to worry about installing external >> libraries and it does what I want, namely give me a hierarchy for >> proteins and a bond information. > > We're talking about two different things here. You want to distribute > your PDB reader with IMP. I don't want to include the code in IMP SVN. > The two issues are orthogonal; if you really want to bundle the > code, we > can do it at makedist time (for tarball releases) or we can use an SVN > externals definition if you want it for SVN users. For the latter, > just > point me to the URL of your SVN repository (presumably this is a path > within the CGAL SVN, or if you prefer I can make a repository for your > PDB reader at svn.salilab.org). > >> the one Frido sent- I don't see how to get bonds out of it, but >> otherwise fine. The documentation really sucks, so I might be missing >> something. > > How are you "getting bonds" out of a PDB file? PDB files don't provide > that information. (The most you can get is the CONECT and SSBOND > records.) For that you generally need a description of the topology, > which is generally covered by the topology file portion of most MM > forcefields. I really hope this stuff isn't hard-coded, because that > would really have trouble with patches and other residue modifications > (think covalently-bonded ligands, acetylated termini, disulfides, > MSE's, > cyclic proteins, nucleic acids, etc.). > >>> Hao's project absolutely requires HETATMs, for example. And I >>> don't share your concern for runtime checks, since PDB reading is >>> not >>> performance-critical. >> My concern on checks was not for efficiency, it was for correctness. >> Depending on strings is poor as capitalization or abbreviation errors >> don't easily get caught. > > I didn't mean you wouldn't have actual atom type objects, just that > they > shouldn't be hardcoded. For example, Modeller reads a set of residue > types from its parameter files at runtime, and after that maps every > residue type in the PDB file from the string to an integer residue > type. > Unknown residue types result in a warning, and the generation of a new > integer residue type at runtime. You could of course use Residue > objects > rather than integer types. > > Ben > -- > ben(a)salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev(a)salilab.org > https://salilab.org/mailman/listinfo/imp-dev -- ben(a)salilab.org http://salilab.org/~ben/ "It is a capital mistake to theorize before one has data." - Sir Arthur Conan Doyle

2 2

score function weights
by Friedrich Foerster 07 Nov '07

07 Nov '07

4 19

Remaining open questions
by Daniel Russel 07 Nov '07

07 Nov '07

1) Hiding the Index classes and making attributes accessed only through the Particles themselves rather than through the ModelData. This simplifies things a lot and we should be able to optimize away most of the overhead later if needed. 2) Decorator classes I vote yes for both :-) And (1) should be done sooner rather than later and effects the DerivativeAccumulator.

1 0

Faking objects
by Daniel Russel 07 Nov '07

07 Nov '07

To elaborate further on my proposal from last night, a particle bundle would look like the following (incorporating some unrelated proposed changes) class XYZBundle { static FloatKey kx_, ky_, kz_; public: XYZBundle(Particle*p): p_(p){} static bool is_instance(Particle *p) { return p->has_attribute(kx_) && p->has_attribute(ky_) && p- >has_attribute(kz_); } typedef std::auto_ptr<XYZBundle> Pointer; Pointer cast(Pointer *p) { if (!is_instance(p)) return Pointer(); else return Pointer(new XYZBundle(p)); } // either static XYZBundle::Pointer initialize(Particle *p) { p->add_attribute(kx_, 0); p->add_attribute(ky_, 0); p->add_attribute(kz_, 0); return Pointer(new XYZBundle(p)); } // or static XYZBundle::Pointer initialize(Particle *p, Float x, Float y, Float z) { p->add_attribute(kx_, x); p->add_attribute(ky_, y); p->add_attribute(kz_, z); return Pointer(new XYZBundle(p)); } Float get_x() const { return p->get_attribute(kx_); } void set_x(Float x) const { return p->set_attribute(kx_, x); } // etc }; The user class XYZBundle::Pointer xyzp= XYZBundle::initialize(p) to add the right fields or XYZBundle::Pointer xyzp= XYZBundle::cast(p) to use. I am a bit uncomfortable about the faking aspect of the design especially without working reference counting. Since Bundles don't need to get passed back and forth from python, we could make the reference counting work. It might be better to just allocate Bundles on the stack. This removes a memory management issue at the cost of eliminating the possibility of using a NULL pointer to signify failure. So things would have to look more like class XYZBundle { static FloatKey kx_, ky_, kz_; public: XYZBundle(Particle*p): p_(p){if (!is_instance(p)) p_=NULL;} bool get_is_valid() const {return p_ != NULL;} static bool is_instance(Particle *p) { return p->has_attribute(kx_) && p->has_attribute(ky_) && p- >has_attribute(kz_); } // either static XYZBundle initialize(Particle *p) { IMP_assert(!is_instance(p)); p->add_attribute(kx_, 0); p->add_attribute(ky_, 0); p->add_attribute(kz_, 0); return XYZBundle(p); } // or static XYZBundle::Pointer initialize(Particle *p, Float x, Float y, Float z) { IMP_assert(!is_instance(p)); p->add_attribute(kx_, x); p->add_attribute(ky_, y); p->add_attribute(kz_, z); return XYZBundle(p); } Float get_x() const { return p->get_attribute(kx_); } void set_x(Float x) const { return p->set_attribute(kx_, x); } // etc }; the the user calls XYZBundle xyzb(p); and xyzb.is_valid() to manipulate a Particle and XYZBundle xyzb= XYZBundle::initialize(p); to initialize.

1 1

Death to objects
by Daniel Russel 06 Nov '07

06 Nov '07

A possible fatal blow for objects came up when talking with Jeremy. Lets say we load a PDB file. It creates a bunch of Particles, some of which are AtomParticles, some ResidueParticles etc. Now it happens I am doing coarse grained modeling, so I only care about the Residues and want to approximate them by a sphere. I have no way of adding a radius attribute to the already existing particle. I have to copy the particle to a new ResidueWithRadiusParticle (and delete the old one) or add a new particle linked to the existing one. Deleting the old residue would break all existing restraints which use the particle.

2 2

Objecting to objects
by Daniel Russel 06 Nov '07

06 Nov '07

I think I have a proposal I like over the other ones: See below or https://salilab.org/internal/wiki/IMP/Particle_objects_or_table - keep the attributes identified by strings - bundle attributes into groups which are presented along with a set of helper functions--this can be done in Doxygen easily - using a string which internally merges its representation (see the web page) - get and set values for the attributes through the Particle, rather than through the attribute table This approach is completely flexible. Users are encouraged to use the helper functions since they are bundled up with the attribute names themselves. Getting an attribute involves a search through a list of integers before fetching it from the table--so not as good as the objects case, but not horrible either and I'll bet we can make the compiler build it to something that is the same as the current Index based version via inlining. There are no changes to IO or the XML or the web stuff. Restraints have to get rid of XIndex classes.

1 0

Tue Nov 11 10-11am
by Andrej Sali 05 Nov '07

05 Nov '07

3 6

Helper functions
by Daniel Russel 02 Nov '07

02 Nov '07

I have various helper functions that are probably generally useful. I am ambivalent about what to do with them. One set is utilities for getting and setting attributes which look like /** Set the value of the string attribute name to val, whether or not it was already there. */ bool set_string(ModelData *m, Particle *p, const String& name, std::string val) and /** Get the string attribute name or return default_value if the particle does not have any such attribute. */ const String& get_string(ModelData *m, Particle *p, const String& name, const String& default_value=String()) Obviously there are int and float versions. Should such things go in to imp proper? On one hand they are extremely useful. On the other it is increasing the size of the interface and while it makes it more convenient, it doesn't add any power. Next I have some helpers for manipulating hierarchy and bond particles (getting the number of children, getting specific children etc). These should go somewhere to establish norms for hierarchies.

3 11

imp
by Andrej Sali 02 Nov '07

02 Nov '07

just occurred to me that I am not capable of following your email threads very carefully, yet I am likely to have opinions about things. we should be meeting every 2-3 weeks. next week? Andrej

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev November 2007