search

mosdef-hub / foyer

A package for atom-typing as well as applying and disseminating forcefields
https://foyer.mosdef.org
MIT License
121 stars 78 forks source link

Precedence of torsions defined using "type" vs. "class" #135

Closed summeraz closed 6 years ago

summeraz commented 7 years ago

Within a force field XML file, torsions (and I'm pretty sure bonds and angles as well) can be defined using either "class" notation, e.g. <Proper class1="CT" class2="CT" class3="CT" class4="CT" c0="2.9288" c1="-1.4644" c2="0.2092" c3="-1.6736" c4="0.0" c5="0.0"/> or "type" notation, e.g. <Proper type1="opls_961" type2="opls_136" type3="opls_136" type4="opls_136" c0="-0.987424" c1="0.08363" c2="-0.08368" c3="-0.401664" c4="1.389088" c5="0.0"/>

The practical use of having both types of torsions defined would be to have the more general case be covered using the "class" notation and defining more specific dihedrals using the "type" notation. It seems to me then that dihedrals using "type" notation should essentially override those defined using the "class" notation; however, the current functionality simply assigns to a dihedral whichever parameters are listed first in the XML. The dihedral parameters are actually assigned using OpenMM, so I'm not sure if this precedence is something they would want or not, but is something I think we should at least implement in Foyer.

chrisiacovella commented 7 years ago

Agreed.

We want bonded parameters that references atom_types to take precedence of bond_classes, as they would be the most specific cases. Given that our atom-typing approach does not rely upon the physical order in which rules are evaluated, we don't want to require bonded interactions to be defined in a specific order.

chrisiacovella commented 7 years ago

In testing, a few things I found: 1- "type" and "class" can be mixed in a single definition 2- if the parameters for two separately defined bonded interactions are the same, the code considers them to only be a single type when it dumps to lammps (I didn't check gromacs, but I assume it's the same behavior). I'm not sure if this makes things cleaner or potentially more confusing.

summeraz commented 7 years ago

Regarding those two findings:

  1. If "type" and "class" can be mixed, then perhaps we want to set the order of precedence based on the number of "type" definitions in a listed dihedral.
  2. I implemented this behavior when writing the LAMMPS writer simply to make the data file a bit cleaner. I had been thinking of going back on this, however, and having the LAMMPS writer write all dihedral parameters (even duplicates) with a comment added at the end that specifies what the dihedral corresponds to (at this point we are dealing with a ParmEd Structure so we will have lost the bond type information, but could at least have a comment at the end of the line that details what elements are involved in the dihedral).
chrisiacovella commented 7 years ago

1) That's a good idea, the highest precedence is the maximum number of "type" and minimum number of "none" definitions 2) Ok, so that's an easy change. I think we should have an option that is "descriptive" output, where we put a comment at the end of each line to say which dihedral parameters these correspond to (so like basically dump the definition string, class1="x" class2="") I probably wouldn't want that in every file, but might be useful to have for validation purposes (of say, a single molecule).