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

From: Joe Krahn <krahn.niehs.nih.gov>
Date: Thu, 12 Mar 2009 14:35:52 -0400

David A. Case wrote:
> On Wed, Mar 11, 2009, Joe Krahn wrote:
>
>> Here is my suggestion for including PDB data in the PRMTOP file.
>
> Don't forget that we need some sort of "not applicable or not available"
> tag for most of these. First, many structures don't have an associated
> PDB file. Even if they do, we add many atoms (hydrogens, waters, ions,
> etc.) that won't have any associated residue numbers, b-factors,
> occupancies, etc. For hydrogens, it probably makes sense to assign
> residue numbers, chain ids etc to be the same as the atoms they are
> bonded to; less clear what to do with all the waters.
I just realized that it doesn't make sense to put B-factors and
occupancies in the PRMTOP. Those values can get refined, and should go
into the coordinate file. If people don't want to complicate the current
coordinate format, it may make sense for the xray code to directly read
and write PDB files as supplemental data that most AMBER don't want to
deal with.

In that case, we can avoid putting "not applicable" items into the
PRMTOP, by always requiring something to be generated if not obtained
from the PDB file. For waters, the easy approach is to assign sequential
residue numbers with the blank chainid starting after the highest
numbered blank-chainid residue in the file.

Or, there could be a "not applicable" flag, in which case the automatic
number can be generated when writing the PDB file, or those atoms could
be optionally excluded from the PDB file. That would give an easy way to
create a PDB file either with or without all of the bulk waters.

>
>> %FLAG ATOM_ELEMENT
>> %COMMENT The element as read from columns 77-80 of the pdb file
>> %FORMAT(5E16.8)
> ^^^^^^^^^^^^^^ typo?
Yes, a typo.

>
>> One field I left out is the altid, but that should map directly to
>> LES_ID, 0->' ', 1->'A', 2->'B', ...
>
> I don't think we should promote confusion between LES_ID and ALTID.
>
I suggested this because I think LES_ID has the same meaning as ALTID.
But, LES can get much more complicated. Maybe the best approach is to
define ALTID, but only use it for simple cases of LES where it may make
sense to write out PDB alternates. So, we should also define an ALTID,
again with 4-char strings to keep things uniform even though only 1 char
is needed.

Joe


_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Mar 13 2009 - 01:26:43 PDT
Custom Search