On Tue, Nov 29, 2011 at 2:30 PM, <dcerutti.rci.rutgers.edu> wrote:
>
> I'd like to bring up topology readers. As I see it, we should ultimately
> support two, or perhaps three canonized readers, one for C, C++, and
> Fortran. I argue that the differences between C, C++, and Fortran are
> sufficient to warrant different data structures for each case, and even if
> there were some master object file that reads the topology and then a
> series of converters to put it into different formats, there would be
> about as much code to maintain as if we had three separate readers.
>
I'll still argue that a Python reader is warranted as well. There are good
reasons to write Python code in our field, enough to warrant a Python API
IMO. I'll hopefully make my case at the dev meeting for this.
My recommendation is that we select, perhaps at the devs meeting, the
> readers that will serve in each capacity. The readers should all do
> precisely the same things, even though information will get filtered
> differently:
>
> - Collect contiguous arrays of charges, Lennard-Jones A and B, bond
> stiffnesses, atom names, etc.
> - Be compatible for parallel execution (i.e. read the topology file as
> ASCII text and then parse the text, so that the text can be transmitted
> through memory to other processes without having all processes trying to
> read directly from the disk)
> - Collect all information deemed relevant by the current standard
>
The current standard is not that well-defined (compare, for instance, a
chamber-prmtop with a tleap-prmtop). This makes a robust, non-Fortran
parser difficult to conform to the 'standard' (which was built for Fortran
parsing).
- Be able to read old-style prmtops as well as "prmtop7" format, with
> automatic detection ???
>
Unnecessary IMHO. These topologies haven't been created (by anybody,
AFAIK) in ~10 years outside of our tleap tests. We could even disable that
ability in tleap (writing old-style topologies).
- Efficient! Clean-coded! Expandable, and robust!
>
I think the most important feature is missing from this list:
Documentation (with common-use examples), and not just stored in comments.
(and clean code is rather subjective, though very clear examples of
unanimously-declared dirty code exist)
IMO, writing a new prmtop parser for your use-case is easier than learning
how an existing one works just by studying code. There is only one parser
in the Amber source right now that I know about that has relatively
extensive API documentation, and you'll see a lot of resistance to
embracing this in practice if no documentation exists.
Comments welcome. At present, we'll probably need to decide amongst the
> readers for nab, mdgx, and ptraj, and the readers for sander and pmemd,
> perhaps cpptraj and any other C++ based code in the tree.
>
Perhaps just a funny comic that is reasonably applicable:
http://xkcd.com/927/
DANGIT ROSS! stealing my thunder. :) Still gotta make my posts shorter...
All the best,
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Nov 29 2011 - 14:00:03 PST
