David A. Case wrote:
> On Tue, Mar 31, 2009, Joe Krahn wrote:
>
>> My own solution is to have PDB name conversion tables in a data file.
>> The file can hold any number of naming variations, and makes it easy to
>> convert among any defined variation. It can also be modified without
>> recompiling anything.
>
> This sounds a lot like the PdbAtomMap and PdbResMap tables in leap. We
> can/should make version2 and version3 variants of these, to make it
> easier for people to use either type of file.
So, ambpdb.f could be updated to read in those tables, or some
simplified form that is easy to parse.
>
>> Using CNS, I created my own set of topology files that use PDB version 3
>> nomenclature. It makes things a lot easier. However, it is not a perfect
>> solution. PDB v3 has a very badly designed atom name alignment.
>> Sometime, it follows PDB v2 element-alignment, but other times it does
>> not. The only way to get it right is to either keep the leading space in
>> tact everywhere, or to add an additional alignment flag data item. Since
>> Leap is too inflexible, it will still probably require a data table.
>
> I don't see that the leading space in v3 is much of a problem,
> myself. And what they have is better than v2. I'm not quite sure what
> inflexibility in LEaP you are referring to, but Wei seems willing to put
> almost any beahvior into sleap, so you should make your needs known.
>
The "evil" of the v3 alignment is that they broke a long standing
alignment rule. In doing so, they SHOULD have gone to simple
left-justification, instead of yet another convoluted alignment scheme,
since we have to update software anyhow. They also did not define an
explicit algorithm for aligning atoms, other than "look it up in the
database".
But, maybe the v3 alignment is easier than I think: 4-letter names for
one-letter elements always shift instead of wrapped. HET names never get
shifted, but this is enforced only by disallowing 4-character names for
1-letter elements. The disadvantage is that you often have to use stupid
atom names to fit this rule, because that one extra character is often
useful.
Earlier you said that leap code was impenetrable, but maybe sleap is far
enough along that this is no longer a problem. My only suggestion for
sleap is that it would be nice to be flexible enough to declare an atom
attribute and save that into the topology, without a hard-wired set of
attributes. For example, someone might want to declare a CHARMM atom
type name that gets saved in addition to the AMBER type name. For X-ray
code, and for PDB v3, atoms should have an element-type property.
Joe
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Apr 01 2009 - 01:17:45 PDT
