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 | Task delegation | - Image RemovedImage Removed
Cerutti support QCA OpenMM energy evaluation Start on knowledge transfer for PE handover → Overlaps most with Dotson Appoint a git branching czar 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
|