Hi Joe,
I agree with this, Charmm does it in their psf's right now and it is useful
in VMD to be able to select by chain etc. The prmtop is extensible so as
long as we agree on a title and format it can be added and sander / pmemd
will safely ignore it. Then we just need to ask the visualization people to
read that information as well and populate their relevant arrays. It should
really be done entirely by X,Y,Z,leap though since postprocessing with
scripts is likely to lead to a lot of confusion. We'll try updating chamber
so it at least includes this info when it reads it from psf files.
Note we should also update the webpage describing the format though since it
is 'very' out of date: http://ambermd.org/formats.html
Maybe Mark will volunteer to do this once he is done with Chamber. ;-)
All the best
Ross
> -----Original Message-----
> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
> bounces.ambermd.org] On Behalf Of Joe Krahn
> Sent: Friday, March 06, 2009 7:55 AM
> To: AMBER Developers Mailing List
> Subject: Re: [AMBER-Developers] Including chain and residue numbers in the
> PRMTOP
>
> 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.
>
> Joe
>
>
> _______________________________________________
> 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 Sun Mar 08 2009 - 01:10:17 PST
