Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Date

Participants

Discussion topics

Item

Presenter

Notes

Infrastructure for bespoke LJ parameter assignment based on QM calculations

Sophie Kantonen

  • Concept is to reduce number of adjustable parameters by not having LJ types but instead to parameterize a mapping from QM to sigma & epsilon for each atom in the molecule. (https://bit.ly/2VnnIsE). See also D Coles’s methods.

  • JW – Maybe could look at implementing this in the toolkit. Touch base with engineering team later in May.

  • DLM – Performance of this method?

  • SK – MEasured using HVap, seems comparable to GAFF, with far fewer parameters.

  • CB – I like the idea. As you put more charge on an atom, the radius goes up, the density goes up. So we’d expect a correlation between charge and radius or beta.

  • MKG – One thing I’d hope to change is that, for a given element, beta determines sigma and epsilon. So sigma and epsilon are correlated. We could introduce another degree of freedom to uncorrelate these.

  • (I lost track of the discussion here)

  • CB – This is reminiscent of Simon’s property calculation work, which implicitly considers all sorts of intermolecular interactions

  • CB – It’d be interesting to see whether, emerging from the map potential, which is based on electronic structure, a correspondence for the purely empirical LJ that come out of the purely-empirical fit. This way, map potentials could guide parameter types.

  • MKG – The challenge is that, when you have a lot of LJ types, it’s hard to be confident that they’ve been optimized enough. This is my big motivation for using less overall parameters

  • CB – If, out of the mapping, bins appear, then this is a good guide to separating parameter types.

Benchmark data

David Mobley

Super brief discussion (5 minutes or less) on coming up with benchmarking datasets to ensure we’re all on the same page. (Basically, just extend work done to select training data to also pick specific benchmarking data.)

  • DM – Are there other fixes we should include in openff-1.2.0 beyond just expanding the dataset?

  • JM – That’s something to focus on more after the May 1.2.0 release

  • HJ – some angles with Sulfur as the central atom are problematic, so I might look at changing those SMIRKS after 1.2.0

  • DM – Should we start generating a benchmark set?

  • HJ – I started a blog post about this. Take a look.

Action items

  •  

Decisions

  • No labels