I was assuming the modeller reader was out for IP reasons, but if we can use it, it would be great if someone could write a bridge for it soon.
On Nov 16, 2007, at 12:57 PM, Ben Webb wrote:
> 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@salilab.org > To: Ben Webb ben@salilab.org > CC: imp-dev@salilab.org > References: 473A42F7.4060005@salilab.org > 473BAF19.30207@salilab.org > B3063E98-E0A6-4032-A70F-CF72419F8441@salilab.org > 473DE358.4000203@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@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@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > -- > ben@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@salilab.org > https://salilab.org/mailman/listinfo/imp-dev