Roundtable updates | CC Been trying to derive library charges for amino acids, and saw differences in AM1BCC charges due to resonance states. So I did a more thorough experiment when in the presence of flanking residues. This made the differences average out. So I’m going to conclude that this isn’t a severe problem that needs immediate resolution. QCF release this weekend. Will try to submit dipeptide torsiondrive set this afternoon. Drafting introduction for LiveCOMS review. Need to continue following up with some other authors. MT had pinged me to play around with Interchange protein-ligand examples. I didn’t get to that last week, so I’ll try to get to it this week.
MT Got a more-openff-based workflow running to take a ligand and protein OFFMol from pdb and an OFFXML or two, and make an Interchange. This is nice since it doesn’t use ParmEd or require a stop through OpenMM. It’s slightly concerning that this workflow uses MDTraj to line up positions. Also right now it uses two different OFFXMLs instead of a single self-consistent force field. This generates water positions on the fly using openff-evaluator’s packmol wrapper. But generally, we could instead approach this by having a full solvent PDB file that we can load separately. JW – OpenMM has a good water-box-maker, in case this is taking several minutes. MT – SB has a nice packmol wrapper, which accepts OFFMols and gives back coordinates in a nice format. This is easier than unpacking vec3s from openmm. Though this does have some friction with the unit systems and pint unitregistries. DD – Does openff-units solve/help with this? MT – Interchange uses openff-units everywhere. Evaluator doesn’t use openff-units yet. We should switch it over eventually DD – I’ll open an issue to discuss switching to openff-units on Evaluator.
I don’t want to guarantee widespread/general correctness using this workflow, but I’m getting consistent energies out from multiple FF engines for systems created this way. CC – Did we ever make a decision on how precisely we want energies to match? MT – We never settled on a number. My intuition is that bonds+angles should agree to 5 or 6 digits. Torsions should agree to 5 or 6 digits, tough sometimes I see differences at 3 or 4. I think this is due to potential issues in functional forms (like, LAMMPS doesn’t support periodic torsions). Impropers are a pain. vdW generally agrees to the 3rd digit. These are messy because of cutoffs and switching functions. ES is more error-prone, due to a whole ton of small issues. CC – This seems like a good assessment and a reasonable goal for now MT – After talking with PEastman, he kinda said that we should expect at most 6-8 digits of agreement, and “that’s enough”. There’s a huge number of factors that contribute to disagreements in practice – For example ParmEd will round bond k’s and lengths to 6 or 8 digits, which can begin propagating errors even before a simulation engine gets involved. Other things like the atom ordering that defines an improper angle will be impossible to standardize across different representations.
Lots of horrible performance bottlenecks – Last Friday I found that it took 2+ minutes to write to a gromacs file, got that down to 10 seconds. Slowest parts are SMARTS matching and charge assignment. Some overhead from using units and doing dimensionality checks.
DD PB Some more fitting related work last week. triple bond params refit with higher force constant - one hmr test fails (prop-1-ynylbenzene) PB – How should I handle this? HJang had C#C bond parameters around 2500 and reported that they passed canary tests. But when I try to do force fields with numbers that high they fail canary tests JW – I think HJang got lucky, or maybe canary tests weren’t implementdd when she did the study. This may be worth following up on (testing HJang’s numbers using the current canary tests)
adding more amide torsions - didn’t improve, checking again new bond/angle params from TG’s chemper work - benchmarks overlap with sage wbo work - need to benchmark more with JACS BACE set biphenyl matches
Will work on sage paper and qca submissions this week, and few more fitting experiments.
JW Released ff14sb_0.0.2 – 22% fewer parameters. More deduplicaiton is probably possible but this first pass was conservative. Also fixed off_impropers file in this release with relative torsion energy difference of 1e-4ish. 2022 planning session w/ PIs was productive. Laid out available effort and possible goals for next year. We’ll meet again to decide on what to pursue. Fragmenter working session w/ Lorenzo, found some unwanted behaviors and documented. This week, will work on fragmenter issues I opened, additional 2022 planning, speeding up toolkit topology refactor.
|