AMBER Archive (2004)

Subject: Re: AMBER: leap problem in AMBER7 (residue insertion)

From: Kuhn, Bernd {PRBD~Basel} (bernd.kuhn_at_roche.com)
Date: Wed Jul 14 2004 - 06:44:00 CDT

Thanks for the hint! The problem could finally be solved by applying
bugfix.8 to the file pdb_read.c. While this fix was written to properly
handle PDB files with large numbers of residues and atoms, the original
AMBER 7 code apparently had also problems with PDB insertion codes. As a
lot of users had already applied this bugfix to AMBER7, obviously, few
could reproduce the observed behavior.
    Bernd

-----Original Message-----
From: owner-amber_at_scripps.edu [mailto:owner-amber_at_scripps.edu] On Behalf
Of David A. Case
Sent: Monday, July 05, 2004 19:22
To: amber_at_scripps.edu
Subject: Re: AMBER: leap problem in AMBER7 (residue insertion)

On Mon, Jul 05, 2004, Kuhn, Bernd {PRBD~Basel} wrote:
>
> when leap in AMBER 7 reads the following PDB snippet (residue with an
> insertion code) it will insert an C-terminus and N-terminus into the
> sequence although the residues 105 and 105A are bonded to each other.

Like Scott, I am unable to reproduce the problem; instead, I get the
expected behavior. It is weird that your LEaP doesn't even pick up the
ILE residue name correctly, but then other very strange things are
happening as well (see below).

It looks like your LEaP is treating the "A" in 105a as a chain_id. See
the place where "starting new molecule" is printed out, line 812 in
pdbFile.c. You may have to debug some around here to see how that
happened.

> Loading PDB file: ./t.pdb
> (starting new molecule for chain (starting new molecule for chain )

Note that the above message is garbled; maybe some string has overrun
memory or something.

The obvious workaround is to not use insertion codes for the time being.

...dac

-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo_at_scripps.edu