Re: [AMBER-Developers] Including chain and residue numbers in the PRMTOP

From: Joe Krahn <>
Date: Fri, 06 Mar 2009 10:54:33 -0500

David A. Case wrote:
> On Thu, Mar 05, 2009, Joe Krahn wrote:
>> I think it would be useful to include the ChainID and residue number in
>> the PRMTOP. It makes selections much easier for defining restraints, and
>> would enable writing a complete PDB file directly from the PRMTOP file.
>> At least some other AMBER users think it is a good idea. Is there any
>> reason not to include the extra atom/residue data?
> The reason with tleap was that the code was inpentrable -- it was not
> simply a matter of adding some more fields to an "atom" struct
> someplace. Data was passed around from one container to another and it
> was beyond my abilities to figure out how to save such information.
At this point, it will require some post-processing to patch the result
of tleap. It is not that hard if built directly from a PDB file with
minimal manipulations. It could be an optional addition for now, and
eventually become standard.

> I assume that Wei can more readily add such info to sleap, since he
> knows the data structures that are used. But it's still tricky to know
> how to handle such information. When does one use internal residue
> numbers (starting at 1) and when to use those in the pdb file. Should
> they be named different things? What to do when residue numbers are not
> "numbers" at all? What does that do to the concept of ranges of
> residues (used in mask commands, etc.) It's something that will require
> a bit of fiddling to get right. Don't forget that anything that is done
> has to be very clearly explained in the Users' Manual.
The current residue number is really a residue index. CNS stores all
residue numbers as string values with insertion codes appended. It works
well, and avoids the need for an extra array of insertion codes. Ranges
can be given with start and end values that are merged
chain+resnum+inscode, but will need some sort of hint to use in place of
existing residue index values. For example, brackets could identify a
selection by actual residue number instead of residue index. In that
case, "[128]" only matches residue 128 with a blank chainid.

For now, I think it would be useful just to have the data in the PRMTOP,
even if AMBER doesn't use it, just for generating a PDB file
corresponding to the original input file.


AMBER-Developers mailing list
Received on Sun Mar 08 2009 - 01:09:39 PST
Custom Search