Hi all,
I agree with Ross, we just need to make a decision on a title and
the format.
Then it would be a simple change to sleap, though I am not sure how
hard it
would be to change tleap though.
Sincerely,
Wei
On Mar 6, 2009, at 10:44 AM, 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
>
>
> _______________________________________________
> 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:20:14 PST
