Progress Updates | JW: update on ingestion components this is the first thing user input hits, so we want to make sure we’re careful about what we accept details on this PR:
this PR Is ready for review; following this, will be working on conformer generation/filling in early next week, since that’s needed to line up for compute input testing DD: I will review, and push to merge! JW: perhaps have a testing party next week
DD: Update on compute component Separating workflow into “Seasons”, where we may want to change the methods that we’re benchmarking Using CLI Openeye loading warning is annoying Showed demo of submitting molecule Working on pulling the data out JW: What all openff versions will we be using? How should we handle different coverage reports?
JH: keeping up with what everyone is doing, synthesizing this into the deployment procedure doc DH: Kicked off discussion on Slack for if we want QM-then-MM vs. QM-and-MM ; not a clear answer yet on what’s preferred Would need intermediates to be stored if we do the then approach DD: the QM final molecules exported could be understood by downstream tools to be the starting points for the MM optimizations JW: Gary’s preference? GT: Would prefer precedence, consistency with what is already published. that said, if we want to show that MM can reproduce the same result, that has value probably start with what has been done, though
DD: can design to the QM-then-MM approach protocol; the approaches can still support the and approach at a later time GT: think it’s important to at least do apples-to-apples with the paper; the other protocol is still interesting, but better for now to approach with the same protocol DH: the and protocol would also present problems for the analysis approach, since it depends on the then comparison JW: how much care is put in to ensure we don’t get duplicates? DH: a bit stuck at the moment; need inputs to work with JW: DD and I can sprint to get the components needed for downstream today
Coverage report: focus on needed data being present first; pretty or human-readable can come after; could be a JSON blob
|