cool! Also - it might be a good time to start discussing other molecule features. For example, Frido and I plan to use a surface generator in the emlib/IMP for the 26S project, which can also be used for generating the non-bonded list.
On Nov 14, 2007, at 11:31 PM, Daniel Russel wrote:
>> As for just a pdb reader, since it only reads atoms and put then in >> IMP we can have in the meantime even a few readers and converge to >> something as time passes. >> I would recommend that we have a few test cases that check main >> functionalities ( multiple positions, HETATMs, chains, >> symmetry ..... ) - so that we can have some objective criteria for >> a final decision. > Agreed. As we want more from the PDB reader we write more involved > test cases and evolve the backend to support what we need. No reason > to jump to a full feature set if that is not easy. > >> I can also offer considering c++ code written in my lab in TA >> which was used for structural alignment and docking procedures - so >> it was debugged well. > Sounds good. The more the merrier :-) > >> >> On Nov 14, 2007, at 6:53 PM, 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). As a result, the >>> code doing the actually reading doesn't matter too much and so we >>> shouldn't worry now about whether we have the perfect solution. We >>> should pick something easy which does what we want and minimizes the >>> amount of effort people have to make. >> >>> >>> When someone needs something more, we can either modify our current >>> solution or chuck it and write an adaptor to someone else's code. >>> Writing these adaptors is trivial given a backend which supports all >>> we want. >>> >>> 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. >>> >>> The alternatives I have looked at so far are >>> >>> BALL- probably dead although it took a breath this morning >>> >>> 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. >>> >>> a few random other C and C++ ones all of which are either >>> embedded in >>> a large library, suck, don't give me bonds etc. >>> >>> One area I haven't looked is the in python only readers. There >>> may be >>> some good ones there. >>> >>>> >>>> If it's an external library, it should be a dependency, not part of >>>> IMP. >>> It depends. Having obscure external dependencies is a good way to >>> piss off people who have to install your software. It is a >>> tradeoff. >>> I would say that we shouldn't depend on anything not in fedora or >>> fedora-extras for something basic like this. >>>> >>> >>>> 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. >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev