> The OFF file is a whole 'nother can of worms :).
Chris invented the OFF format, and like the 3D editor it's is one thing
that may remain about the same as the original (I didn't touch it).
Bill
On 9/21/16 5:48 PM, Jason Swails wrote:
> On Wed, Sep 21, 2016 at 4:09 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>
>> Hi,
>>
>> I'll do my best to answer these questions - corrections from others are
>> welcome.
>>
>> On Wed, Sep 21, 2016 at 1:10 PM, Christian Schafmeister
>> <drschafmeister.gmail.com> wrote:
>>> QUESTION #1: The excluded atom lists are indices into the atom tables
>> in increasing numerical order?
>>
>> I think so, yes (related to #2).
>>
> Yes.
>
>
>
>>> QUESTION #2: The excluded atom list only includes indices (j) where j>i
>> for atom_i?
>>
>> Yes.
>>> QUESTION #3: Excluded atoms are 1-2 (stretch) and 1-3 (angle)
>> interactions What about 1-4 (dihedral) interactions, are they in the
>> EXCLUDED_ATOMS_LIST or not?
>>
>> Yes 1-4 interactions are excluded.
>>
>>> QUESTION #4: Is there anything important I’m missing about non-bonded
>> interactions? Magical negative indices or values or something that have
>> special meaning?
>>
>> A negative index in NONBONDED_PARM_INDEX means HB term, otherwise it's
>> a LJ term (mentioned in the docs).
>>
> Currently, none of the codes permit both 10-12 and 12-6 terms exist for
> the same system. I have seen prmtops where water atoms were assigned
> elements in the 10-12 arrays that were set to zero, which I think was a way
> of "marking" them for SETTLE. But that convention is no longer used. (I
> came to that conclusion based on a number of comments across different code
> bases).
>
> A few other gotchas:
>
> 1. The 1-4 nonbonded list is constructed from the dihedral lists (dihedrals
> with H and without H). To indicate that a pair of atoms should be included
> in the 1-4 nonbonded calculation, exactly one of the terms needs to have
> its third atom index be positive. All others (such as multi-term torsions
> and one of the 2 distinct torsions in a 6-member ring that have the same
> end atoms) need to have its third atom index be negative. Likewise, any
> pair of atoms that are ends of a torsion *and* either an angle or bond
> (true for 5- and 4-member rings), all of those torsions need to have their
> third index be negative (since the 1-2, and 1-3 exclusions trump the 1-4
> exception rules). All impropers need to have its fourth atom index be
> negative (and, since there is a central atom and no pair are ever separated
> by more than 1 bond, the third is always negative too).
>
> A consequence of this is that if a torsion involves the first atom (whose
> index would be "0"), the ordering must be reversed if that atom appears
> third or fourth in the torsion list if it's either improper or an omitted
> term.
>
> 2. The last quirk I recall about the exclusion list is that for atoms that
> either have no exclusions (like ions) or whose excluded pairs have a
> smaller index, they are assigned a *single* exclusion to the non-existent
> atom 0 (since the prmtop uses 1-indexing everywhere). Extra points also
> have weird rules. They have the same exceptions as their parent atom.
>
> Amber programs rebuild the exclusion list for PME calculations, but use it
> for GB calculations. If you want to test assignment of the exclusion list,
> you will either need to stick with non-periodic test systems (which don't
> support virtual sites) or use ParmEd's OpenMM integration (which *does* use
> the exclusion list in the prmtop).
>
> The PDF file you found is a brain dump I committed to (what has come to
> replace) paper several years ago. Another source of weird quirks are the
> ParmEd comments, but the ones I listed are the big ones I remember learning
> about.
>
> The OFF file is a whole 'nother can of worms :). I also documented that
> format awhile ago: http://ambermd.org/doc/OFF_file_format.txt, which is
> just a somewhat refined and condensed summary of tleap code, comments,
> commit logs, and experimentation :).
>
> The parsers and writers in ParmEd are fairly mature, and have undergone
> several iterations of finding and fixing bugs for weird corner cases. It
> may be a helpful resource if you can grok the code there (
> https://github.com/ParmEd/ParmEd/tree/master/parmed/amber). Support for
> the CHARMM force fields would also be cool :).
>
> All the best,
> Jason
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Sep 21 2016 - 20:00:02 PDT
