Progress reports | Dotson Thompson Boothroyd 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 |
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 Github link macro |
---|
link | https://github.com/openforcefield/qca-dataset-submission/issues/79 |
---|
|
Should run MM energy calculations in QCA – Do we want to run on existing QM geometries, or regenerate torsion scans using MM ffs? Check for connectivity rearrangement? 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 Github link macro |
---|
link | https://github.com/openforcefield/openforcefield/issues/549 |
---|
|
Couple with transfer of CI to GHA? 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
|