> 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.
I don't understand why it needs to be this complicated. Why not just include
both sections in the prmtop file. The key is that it needs a comment about
the fact that sander and pmemd don't use that data and just ignore it. The
real advantage is for visualization programs which will all need to be
updated to read this info so they can display it within the program. Thus we
need to define a very clear and concise standard for including this in the
prmtop file so we can tell people like John Stone (VMD) what they need to
read.
Additionally remember that many programs read amber prmtop files - don't
forget that you will need to update ambpdb as well as ptraj and a bunch of
other codes to make sure they read this data.
I would avoid the issue of having some kind of flag in there that is
initially off and then later turned on since I think this will just make the
code more confusing and I suspect that down the road the purpose of this
flag will ultimately get lost and then people won't be able to follow what
is going on or why it is there. Why not just have two sections similar to
the following (with more detailed comments of course):
%FLAG RESIDUE_INDEX
%COMMENT The residue indexes as generated by Leap
%FORMAT(10i8)
1 2 1 ......
%FLAG RESIDUE_NUMBER
%COMMENT The residue number as read from the pdb file
%FORMAT (10i8)
1 2 3 .......
These sections can go immediately after the RESIDUE_LABEL flag in the prmtop
file. Remember though that if you update the prmtop file you need to test
EVERYTHING including third party applications that are commonly used (VMD,
Sirius, Chimera, ...) including both current and previous versions (probably
back to at least AMBER 8 in amber) and then put together any necessary
patches and/or contact the third party software authors and explain what has
changed and ask them to update their codes.
All the best
Ross
/\
\/
|\oss Walker
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
|
http://www.rosswalker.co.uk | PGP Key available on request |
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Mar 08 2009 - 01:21:15 PST
