2021-01-11 Core Developers Meeting notes

Roundtable updates

• SB

  • Looking into new bug in MDTraj (multi chain PDB file mangles atom indices) – Reported

  • Found and reported vdW/rmin_half error, and helped with bugfix.

  • Found usage issue with Pint – Version 0.15 and later have some sort of regression. Now Evaluator doesn’t use Pint dynamic classes. If we end up centralizing on a single unit repository, we should likely use this approach.

  • Been working on a FF diagnostic dashboard, for stiketeam-like tasks

• MT

  • vdW bugfix and release

  • Slow and steady progress on interoperability. Last week, managed to get pint+pydantic units working in a way that my discussions with SB and JW identified.

• CD

  • Been working on molecule perception/parameterization equivalence testing between RDKit/OpenEye. So far comparisons looks pretty good in terms of InChI and SMILES comparison.

  • About 320/350 molecules pass are_isomorphic

  • RDKit fails to load some MiniDrugBank.sdf molecules. Not sure why or how severe this is.

    • MT – Noticed that some tests load MiniDrugBank from mol2, kinda strange that these don’t use sdf

    • JW – This is basically a legacy behavior that I haven’t pulled the plug on.

  • Thinking about using SMIRKS matches to compare molecules

• DD

  • Worked on rapid development cycles for benchmarking compute, especially with regard to QCFractal deployment.

    • Different setups raise different problems, which is hard to interface with

  • Made #benchmarking-support channel

  • I’ve been delayed in getting public datasets submitted, currently focusing on software.

  • Planning to work with Xavier Lucas on usage questions with torsiondrives

  • Want to get local QM job running capabilities for debugging runs. Will require some changes to QCEngine, which I think we can get released quickly.

  • Will be contacting partners to understand how they’re going to run their QCFractal jobs, so I can be prepared to support their execution pathways.

  • Aiming to be feature-complete on openff-benchmark CLI by the end of this week.

• JW

  • Had a lot of meetings

  • Made vdW bugfix with Simon and Matt.

  • Cleared half of PR backlog.

• PB

  • Started doing experimental fits using 1.3.0 as initial FF, but cancelled because of vdW issue.

  • JW – Seemed to be combination of 3 issues:

    • Toolkit vdW bug caused the repulsion to be inadequate

    • 1.3.0 relaxed valence terms allowed for those closer contacts

    • Minimizer shouldn’t have ended on such a high energy structure (it’s not a “minimum”)

  • SB – Minimizer failures could be due to a fixed step size in a steep energy landscape

  • PB – Alternative minimizers?

    • SB – Could use FIRE minimizer from openmmtools

      • JRG – I’ve have good experiences with FIRE minimizer, though I had to wrap it with ASE(?)

  • PB – Wrapped up QCSchema roundtrip issue, ready for review.

  • PB – Found a mistake in one of the datasets I submitted regarding tautomers, generated a new submission

    • DD – This is good to merge

  • PB – This week, will be updating benchmarking results and looking more into interpolated parameters.

• JRG

  • Worked on tons of changes with conda-forge. Lots of nvidia stuff, especially around Windows+GPUs.

  • Tried to split the conda-forge migration PR, but I could only cleave off one subset (openmoltools, openmmtools, etc)

Discussion topics

• MT – Future of omnia? Nobody wants to own it, and much of its machinery seems to be travis-based (which will shut down their open-source tier soon). Omnia was originally built to support OpenMM’s GPU wonkiness, maybe now it’ll just become our “legacy openeye dependent” channel

  • SB – If we really can’t get rid of hard OE deps, we could just make individual feedstocks using conda-smithy. But big +1 would be to make a friendly import error and release on C-F.

  • JRG – Having omnia in channel lists at all adds complexity to conda dependency solving. It’d be better to migrate completely off of it. If we absolutely need to keep omnia around for OE packages, I agree with SB that we should make an omnia-smithy

  • JW – What about openmm nightlies?

  • JRG – I can handle that in a special smithy. I’ll be taking over some management of openmm devops/nighly builds.

  • (General) – Remaining packages with hard openeye dependencies seem to be fragmetner and perses – If we make these soft they’ll be safe to move to conda-forge.

• JRG – openforcefield → openff-toolkit migration timeline?

  • JW – Was going to hand over the keys to SB and MT

  • SB – Are the new repo names good? (openff-toolkit and openff-forcefields?)

    • JW – Yes

  • JRG – Issues with changing the repo name? Re: miniconda-setup issue?

  • JW will handle migration messaging (on slack and twitter)

  • JRG – Make sure to update actions on forks – There is a condition in a CI file that has the repo name hardcoded

  • SB – I’ll check to make sure that the CI remains sane after name changes.