Fix some bugs in smirff99Frosst

[davidlmobley]

I did some work checking smirff99Frosst parameters and energies against parm@frosst parameter/senergies for AlkEthOH's chain molecules. Because smirff99Frosst is a more general forcefield, with a lot of specialization removed when Christopher Bayly did not deem it well-supported by the data, energies/parameters should not necessarily reproduce exactly. So, I created a specialized smirff99Frosst_AlkEthOH.ffxml file (added here in utilities/convert_frosst) which adds back in specialization that he deliberately removed and proceeded checking details of any inconsistencies until energies and parameters reproduced perfectly for the entire set of chain-like molecules in AlkEthOH (more than 900).

In the process, I uncovered a number of small bugs in the smirff99Frosst itself, typically human error in SMIRKS string creation and/or parameter entry which this PR fixes, including:

• fix a [#6X4]-[#8H0] bond length (omitted before)
• Fix a bug in torsion smarts pattern corresponding to parm@frosst/parm99 types HO-OH-CT-CT
• Fix underly broad X-C_-O_-X torsion which didn't recognize X-OS-CT-X
• Fix overly broad CT-CT-OS-CT torsion (which had generics in the first and last positions as was overriding parameters above it in the hierarchy)
• Fix omitted HO-OH-CT-CT torsional term

This PR fixes these issues.

I don't plan on checking the "rings" subset of AlkEthOH's molecules, as Christopher consolidated parameters for internal angles in rings considerably (with the thought that these can be re-learned if needed) since typically the geometry will constrain the equilibrium angle enough that these are not particularly important. Hence, we expect lots of parameter differences there.

@bannanc - can you skim the SMIRKS quickly for me?

[davidlmobley]

For code review, @bannanc , you should focus on the source "Frcmod.txt" files; since the ffxml files are generated programmatically from these, they have more changes. The only thing that needs checking is the isolated changes in the source text file.

[bannanc]

This section was in the middle of the generic ring section before. The numbers haven't changed. Noted for the recorded nothing wrong here.

[davidlmobley]

I don't actually follow this comment, @bannanc . Can you clarify?

[davidlmobley]

On further consideration I think I need to put the order back to what it was (which is maybe what you're saying); I thought this was a mistake where it was because of the "specialized angles override generics" approach generally used, but in reality though these are sort of generic, they are more specialized (for rings) than what follows and with my modification, will get overridden by the non-ring parameters following. I'll move it back.

[bannanc]

Everything except for the comment I made about the *-CT-O-* torsions look good to me.

[bannanc]

@davidlmobley it looks like you're removing the generic *-Csp3-O-* torsions. Is the reasoning here that the parm99 numbers were for CT-CT-OS-CT are we sure Christopher didn't combine anything into those generics?

[davidlmobley]

Could be I just accidentally deleted a couple extra lines; I got interrupted by something in the midst of a deletion at one point; I will check in the morning. Thanks.

[davidlmobley]

Ah, right, no, this was not a deletion, just a change. For the record, on the lines 365, 366, and 367 from above I changed the wildcard in the first position to #6X4, and the wildcard in the last for 366 and 367 to #6X4.

Anyway, line 365 was definitely a bugfix, @bannanc - if you look at it, it overrides line 364 EXACTLY. Christopher appears to have just duplicated the SMIRKS pattern from the previous line and then never corrected it to match the specified pattern (CT-CT-OH-HO). The other two result in parameter inconsistencies with parm@frosst when applied to AlkEthOH because a generic torsion is otherwise applied in that case. There's nothing in his files which indicates he made this choice deliberately, so I'm interpreting it as an overly broad CT-CT-OS-CT (i.e. I'd want to see at least carbon in the first and last positions; also, normally he placed generics at the top of sections, so it would be out of place to have a generic here when it's preceded by more specialized torsions already).

Another argument in favor of my view is that I think we want this force field to be like parm@frosst except when we're removing unnecessarily specialization. The issues corrected on lines 366 and 367 are in the opposite direction -- Christopher had (accidentally, I believe) added additional specialization not present in parm@Frosst.

I'll try and discuss it with him the next time we talk, but I'm pretty confident in these changes. :)