I just had a simple idea about avoiding residue-number versus
residue-index conflicts. There can be a flag to enable the new residue
number syntax, which can initially default to off, and eventually
default to on. When enabled, the residue index could still be available
with a syntax like "#123".
I will go ahead and implement something, because it will make things
easier for comparing SANDER output with crystal structures.
Joe
Ross Walker wrote:
> 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
Received on Sun Mar 08 2009 - 01:19:32 PST
