The torsions and impropers are kept as lists of atom numbers - no
attention is paid to atom type strings once the prmtop is generated.
Bill
On 3/25/16 8:07 AM, David Cerutti wrote:
> Yes, I agree--in the mdgx topology data structures, for executing the
> energy function, the propers and impropers are all in a list, but each has
> a flag. For parameter development, there is again one long list of
> "dihedral" data structures read from the parm.dat files, and again each o
> them has a flag 0 or 1 to indicate proper or improper. Furthermore, in the
> parameter data, there is a partition between the propers at the start of
> the list and the impropers at the end, and I keep track of the counts of
> each. I did not know that the types are not necessarily alphabetized in a
> parm.dat or frcmod file, but I do have code in there to check when reading
> those parameter files.
>
> On Fri, Mar 25, 2016 at 8:47 AM, Jason Swails <jason.swails.gmail.com>
> wrote:
>
>> On Thu, Mar 24, 2016 at 10:47 AM, David Cerutti <dscerutti.gmail.com>
>> wrote:
>>
>>> It seems that Dave Case's insight is important:
>>>
>>> "The only invariant thing you can do with a torsion (proper or improper)
>> is
>>> to reverse it: ABCD == DCBA. All other permutations are different."
>>>
>>> This jibes with the way the rest of Amber lines up impropers so that they
>>> can be treated just like any other torsion. However, it seems I now
>> have a
>>> slightly different problem. In the topology that the student created,
>>> which I have attached, it appears that there are BOTH proper and improper
>>> torsions with atoms c3 na ca ca. I am reading the topology verbatim,
>> and I
>>> find the following dihedrals (without hydrogens):
>>>
>>> 23 24 25 26 c3 c3 n4 c3
>>> 23 24 25 27 c3 c3 n4 c3
>>> 23 24 25 28 c3 c3 n4 c3
>>> ...
>>> 22 1 4 8 c3 na ca ca
>>> ...
>>> 22 1 2 5 c3 na ca ca
>>> ...
>>> 22 1 -4 -2 c3 na ca ca
>>>
>>> In the (abridged) list of dihedrals above, I have taken care to divide
>> each
>>> array index by three, add 1 if was positive, and subtract 1 if it was
>>> negative. In this manner I am giving the atom numbers (first atom
>> starting
>>> at 1) of the atoms involved in various dihedrals, and making those
>> indexes
>>> negative if the topology is trying to tell me that the dihedral is an
>>> improper. I then give the type of those same atoms, in the same order.
>>> Note the final three dihedrals: these are the infamous "c3 na ca ca"
>>> beasts. This exposes one vulnerability in mdgx parameter fitting, that
>>> when it is confronted with a parm.dat file containing proper and improper
>>> dihedrals with the same atom type sequence one will overwrite the other.
>>>
>> Why do you store impropers and propers in the same list? Don't do that!
>> tleap doesn't. The parameter files don't (i.e., the parm.dat and frcmod
>> files). That the prmtop does is an implementation detail of the force
>> field tied to how it's implemented in the MD engines. If you want to
>> emulate tleap behavior, impropers and propers should be in separate lists
>> or hash tables. They are assigned differently and are unrelated (except
>> that they share the same functional form... but in some sense so do angles
>> and bonds).
>>
>> Also, the ordering is done at the time that LEaP writes the prmtop (or
>> maybe when it's assigning the parameters, but I actually think that's done
>> at prmtop writing time as well, I can't recall), not in the actual
>> assigning. The types don't have to be alphabetized when written to a
>> parm.dat or frcmod file. tleap will check the permutations as needed, I
>> believe.
>>
>> All the best,
>> Jason
>>
>> --
>> Jason M. Swails
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Mar 25 2016 - 12:30:05 PDT
