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
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?)
0 Comments