Re: [AMBER-Developers] Topology file readers

From: Jason Swails <>
Date: Tue, 29 Nov 2011 16:53:47 -0500

On Tue, Nov 29, 2011 at 2:30 PM, <> 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

- 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:

DANGIT ROSS! stealing my thunder. :) Still gotta make my posts shorter...

All the best,

Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
AMBER-Developers mailing list
Received on Tue Nov 29 2011 - 14:00:03 PST
Custom Search