2020-03-30 Core Developers Meeting notes

Progress reports

Dotson

• Nothing yet – Onboarded last week

Thompson

• Not a ton – Onboarded last week

• Worked on #551 to implement parameterhandler.get_parameter – Needs review

Boothroyd

• Worked on mixture feasibility studies, working on codebse for surrogate mdoeling

Horton

• Defended thesis

• Adding CMILES functionality to OFFTK – Needs review?

• Adding state enumeration, available in newest release of RDKit

• First draft of QCSubmit working. Need to set up Travis testing.

Hahn

• Worked on free energy difference workflow – “PMXWorkflow”, based on de groot scripts. Original code needs refactor, new workflow not yet public. Some question about “ownership” – I am not free to give it away, since it’s not clearly mine. Would like to post somewhere public.

• Continued on PLBenchmark repo

Wagner

• Onboarded new SSs and Cerutti

• Working on SDF charge I/O. SDFs are complicated and not isomorphic to OFFMols.

  • SB – Pick one serialziaton format for OFFMols on disk

  • DD – A C++ codebase would be able to read a standard serialization format. Or other projects could use a python interoperability layer to load our molecules

  • SB – We should stick with objects being in one language

  • JW + SB – If we use Pydantic to define our object model, we should be able to dump out a language-independent schema represenataion of our data structure.

  • DD – Agreed

• Working on chargeincrementmodel PR – Need to check with Yuanqing about API

• Working with Gokey on virtualsite support – Expect changes to Topology and Molecule

Jaime

• Negative feedback from c-f on policy proposal for openmm compatibility

  • This is kinda good, since now we can talk with PKE about moving forward with a specific openCL management model

Task delegation

•  

• @Jeffrey Wagner – Cerutti support

• @Matt Thompson Take over dev docs branch

• @Jeffrey Wagner #281, Chargeincrement PR. Torsion WBOs

• @David Dotson #305, #379, #381

• @Matt Thompson (primary) @David Dotson (secondary) QCA OpenMM energy evaluation

  • Should run MM energy calculations in QCA – Do we want to run on existing QM geometries, or regenerate torsion scans using MM ffs?

    • Probably start with QM geometries

    • If possible, should run evaluations in QCA

  • Check for connectivity rearrangement?

    • Would be nice

    • Could use WBO cutoff to detect connectivity

  • Josh’s offmol.from_qcschema can do much of this

• @David Dotson (primary), @Matt Thompson (secondary). Start on knowledge transfer for OpenFF Evaluator handover → Assign a few issues

• @Matt Thompson Appoint a git branching investigator (Due mid-april / new model adopted starting at 0.7.0 release)

  • Will present on tradeoffs of each strategy, and drive a vote on Monday

  • SB – would be good to copy a model from community if possible (scipy, DASK, numpy, etc). Also I’m against having a continuous RDKit-only dev branch, and OE-also dev branch.

  • JRG – Initial reviews could be RDKit-only. Then we have a second internal step on an internal branch, and opens a second PR that depends on the first (where we test OE). Intermediate branch could be temporary.

  • JRG – Maybe we don’t need a second PR branch for OE. If we migrate to GHA, we could use metadata in the PR to accept

• Slay the OpenEye license/branching beast

  • Couple with transfer of CI to GHA?

    • No

  • Probably want an “RDKit-only” contributions branch

  • Automation so that a malicious user can not open PR into master/access oe_license

  • Policy for accepting OE-only features (never allow? Require RDK equivalent?)

• @Jaime Rodríguez-Guerra (Deactivated) Migrate OFFTK CI to GHA

  • @Jeffrey Wagner will add OE license as secret, jaime will say when/how