/
2020-10-14 OpenFF Benchmarking : Tools for Partners Meeting notes

2020-10-14 OpenFF Benchmarking : Tools for Partners Meeting notes

Date

Oct 14, 2020

Participants

  • @David Dotson

  • @David Hahn

  • @Trevor Gokey

  • @Joshua Horton

Goals

  • Josh Horton will demo the one-shot torsiondrive script he has developed

  • David Dotson will get feedback, nuanced discussion from the group on the project plan components

Discussion topics

Item

Presenter

Notes

Item

Presenter

Notes

FF choices

David H.

  • the following forcefields are desired:

    • smirnoff99Frosst

    • openff 1.0.0 1.1.(0,1) 1.2.1 (latest)

    • gaff2.1

    • OPLS3 (probably not possible, but of high interest to industry partners)

      • is it possible to get an older OPLS running

      • would have to be a separate software path; we can establish a set of parameters everyone should use, David H. has experience here he can provide

Input format



  • 3D SDF likely as the canonical input format

Software approach

Josh

  • JH: Should have its own repo

  • DH: Agree; should have its own repo

  • TG: Wanted to do single points for TorsionDrive quite often; would tend to group this tooling with analysis approach

  • DD: Agree on its own repo, will allow us to move quickly, have its own issue, PR space; will be duct-taping together components imported from QCSubmit, benchmarkff, etc.; generalizable things can make their way elsewhere if desired when we make things prettier

Missing components

David D.

  • DH: if we wanted to compare torsiondrives, then we would need new functions

  • DD: Optimizations easy by comparison; hoping this remains out of scope; will get their opinions on 10/23

OpenEye warnings

David D.

  • How can we make the loud OpenEye license complaints go away? Technically not a problem, but optically can be confusing or a turn-off for users

    • TG: comes from the C executables; hard to make it disappear in the OpenFF toolkit Python layer

    • JH: if we don’t install OpenEye, won’t get the warnings

    • DD: can we remove OpenEye as a hard dependency?

    • JH: Fragmenter pulls needs it and pulls it in

    • DD: Can we remove fragmenter as a hard dependency, since we only use it in a couple places?

    • TG: I think it’s already imported where needed; could remove as hard dependency already

    • JH: will remove Fragmenter, OpenEye from hard dependencies next conda release

“Readily usable”

David D.

  • What would count as readily usable data structures/output?

  • JH: Have you ever used yank? produces a bunch of Jupyter notebooks, featuring rendered plots

  • DH: Figures are good; data formats should be simple

    • CSV files work, with column definitions

    • JSON is readable, but a bit more complex

Action items

@David Dotson will solicit names for the package we’ll build for this project in #benchmarks-partners; follow up with poll for selection
@Joshua Horton will remove Fragmenter, OpenEye from hard QCSubmit dependencies for next conda release
@David Dotson will address input on https://openforcefield.atlassian.net/wiki/spaces/FF/pages/760086545 ; iterate where possible until October 23 meeting with partners

Decisions