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
https://salilab.org/mailman/listinfo/imp-dev