Since Jason didn't say this explicitly: If you're gonna bother with fortran-style formatting, using the FLAG and FORMAT specs is important and should not be ignored, no matter what anyone else does (even if they -are- Jason's elders and he should be more respectful... ;-). You cannot assume there will be white space in this style of formatting, so it is really important to let parsers know how the line will be divided.
I have a prmtop reader, too! In fact, we have two from our group. We should all get together and form a club. Or a committee. Or at least sit around and drink. Oh, yeah... we do that at the annual meeting....
We really need to update the docs. Ross's offer of a drink obviously hasn't been enough to entice me to do it. Maybe in my spare time (ha...). Jason, did I interpret your comments as meaning you're doing that? If so, then yay!
:-) Lachele
Dr. B. Lachele Foley
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.ccrc.uga.edu
________________________________________
From: Jason Swails [jason.swails.gmail.com]
Sent: Monday, October 24, 2011 7:47 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] prmtop file format specification/documentation
Hey Tim,
On Mon, Oct 24, 2011 at 7:19 PM, Timothy J Giese <timothyjgiese.gmail.com>wrote:
> I've been writing some code to read prmtop files.
> I've been looking at http://ambermd.org/formats.html as my sole source
> for the specification.
>
> I have a few questions (for now).
>
> (1) The specification suggests that %FLAG and %FORMAT are a part of the
> specification, but some prmtop files in the amber distribution don't
> have these. Are these not a part of the specification or are those
> prmtop files malformed? Perhaps my reader should ignore these because
> everybody else is?
>
These are pre-parm7 format (a new format introduced as part of Amber 7).
These topologies are older than I am (not quite) and are not created
anymore. They only hang around because they are as old as the tests that
haven't changed in quite some time.
Feel free to ignore them, since they can't be used for many modern
calculations.
>
> (2) The %FLAG POINTERS section described in the specification suggests
> that it should contain a list of 32 integers, but all the prmtop files
> that I've found contain 31 integers.
>
The way I interpret this is that it *can* contain 32 integers (and indeed,
32 are read in), but ncopy is rarely there (at least in the topology files
I've seen). In my own Python prmtop parser, I had to catch an IndexError
loading that last pointer since it rarely exists. If you look at the sander
code, though, it will be read in and loaded as ncopy if it's present.
>
> (3) The pointer NUMEXTRA is described as "extra points found in the
> topology"; however, the remainder of the documentation neglects to ever
> again mention the words "NUMEXTRA" or "topology" - so it's unclear to me
> what and where these extra points are. Do these affect the numbering of
> all the atom index arrays - or perhaps how one of the sections is to be
> read - or something else entirely? My only real concern here is
> understanding how a non-zero value of NUMEXTRA effects the reading of
> the numbers and how that changes the meaning of the numbers.
>
As I understand it, extra points are considered in many cases to be atoms (I
think they have "atom names" and "atom types" defined to be "EP" (or EPW in
the case of TIP4Pew waters). Thus, the number of "real" atoms can be found
by subtracting NUMEXTRA from NATOM. (I just created a topology file from
TIP4PBOX to verify this). However, there are some routines in sander/pmemd
that give special treatment to extra points, so it's helpful to know how
many they are ahead of time. For all intents and purposes, however, they
are represented as atoms (and have properties in every atom-property array).
NUMEXTRA isn't better-documented because I don't use them (yet) and haven't
familiarized myself with how they're handled in Amber, and I was the one
that updated the spec documentation (which hadn't been touched since well
before the format changed in Amber 7, unless I'm mistaken).
> (4) %FLAG EXCLUDED_ATOMS_LIST suggests that INB is an array of atom
> indices. This makes me believe that these are numbers from 1 to NATOM;
> but I see that some prmtop files have values of "0". Is this a
> c-offset/fortran-counting number issue or is there some undocumented
> meaning to a value of 0?
>
This threw me off when I was trying to compute an exclusion list (for
re-creating a topology file after deleting some atoms). Basically, the 0 is
a placeholder for atoms that have no exclusions. Many atoms have 0
exclusions since atom pairs are only excluded once by the lower-indexed
atom. Thus, for high-index H-atoms, they will have no exclusions, since
they're part of the exclusion list of the heteroatom. I don't know why they
didn't just put the 0 in the NUMBER_EXCLUDED_ATOMS list for that atom, but
maybe some of the code required every atom to have at least one index, and
it just ignored 0s. That's why you don't see any exclusions in
NUMBER_EXCLUDED_ATOMS, since everybody will exclude atom 0 if nobody else
(which doesn't exist in standard Fortran arrays, as you already know).
Depending on what you're trying to do here, though, you may be able to use
some of the existing prmtop parsers. There is a parser written in Fortran
(obviously) that's part of both sander and pmemd (same parser), one written
in C (for ptraj), C++ (cpptraj), and Python
($AMBERHOME/AmberTools/src/parmed/chemistry/amber/readparm.py in the current
git tree)
Hope this helps,
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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Oct 24 2011 - 17:30:02 PDT
