Ross Walker wrote:
>> 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
>
There doesn't need to be any RESIDUE_INDEX data. The residue index is
just a flat index: 1, 2, 3, 4, ... ,NRES.
My suggestion was only to answer Dave's question about how to avoid
conflicts in input files that refer to a residue number. An easier way
to do it is just by the presence of %FLAG RESIDUE_NUMBER in the prmtop
file. If present, and the software knows how to read it, it gets used.
If not, the original residue array-index is used for RESIDUE_NUMBER, and
things are no different from the current output of leap.
So, the only reason to have some sort of flag is if someone wants
backwards compatibility to old input files with the new RESIDUE_NUMBER
data. That can be done by stripping the new RESIDUE_NUMBER data.
Joe
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 11 2009 - 01:29:00 PDT
