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 3 Next »

Date

Participants

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

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

Decisions

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.