Re: [AMBER-Developers] antechamber default residue name

From: Timothy J Giese <>
Date: Tue, 07 Jan 2014 15:11:13 -0500

On 01/07/2014 02:36 PM, wrote:
>> On 01/07/2014 01:22 PM, Timothy J Giese wrote:
>>> antechamber -i PM3BP.U.pdb -fi pdb -o PM3BP.U.mol2 -fo mol2 -c bcc -s 2
>>> -nc 0
>>> It produces PM3BP.U.mol2, but the residue name is left blank in the mol2
>>> file.
>> OK. Nevermind. It looks like the problem is when the residue name in the
>> pdb file has only 1 character. If I change it to two characters, then
>> it works fine. Sorry about that.
> This still sounds like a problem: one-character residue names are
> perfectly legal and very
> common (e.g. A, U, G, C). So we need to remember this problem, and get it
> fixed.
> The Amber bugzilla site would be a good place for stuff like this, but is
> horribly under-used
> (at least by me....)

Sure - OK. Well, let me just finish this off.

The issue is in antechamber/pdb.c function rpdb
which assumes that the residue name is left-justified.
(My residue names were right-justified.)

if (cinfo.rnindex == 0) {
   atom[numatom].aa[0] = line[17];
   atom[numatom].aa[1] = line[18];
   atom[numatom].aa[2] = line[19];
   if (atom[numatom].aa[1] == ' ')
       atom[numatom].aa[1] = '\0';
   else if (atom[numatom].aa[2] == ' ')
       atom[numatom].aa[2] = '\0';
       atom[numatom].aa[3] = '\0';

The PDB standard explicitly states the starting position of the
atom-name, but (correct me if I am wrong) it leaves ambiguous the
starting position of the residue-name. See subsection "Details" in:

The reason why it worked when I used a two-character residue name was
because this caused .aa[1] != ' ', which then ultimately set .aa[3] =
'\0' as intended. (There is no test for .aa[0]==0, so it allows for a
little play in the justification of two-character residue names.)

Moving the 1-character residue name from position 20 to position 18 or
19 also gets around the problem.


AMBER-Developers mailing list
Received on Tue Jan 07 2014 - 12:30:02 PST
Custom Search