Roundtable Updates | PB SB Rewriting evaluator, trying to do thermodynamics derivatives instead of finite difference. Should be possible by integrating timemachine. Solvation FE gradient support, figuring out how to do reweighting.
DH MT Lots of scattered work. Good progress on System object. Got some clarification about what we’ll do (build something so that we can compare specs). This is helping to clarify which decisions we need to make (eg. positions in Topology?) Doing a lot more documentation on openff-system repo Design discussions for System → MMOSS Slack SB – What is ultimate goal of VU collab? MT – Grant was co-awarded with us and VU. Lots of big-picture overlap, though it’s hard to work on the low level with different organization structures. Some marginal benefit in exporting to HOOMD and KASSANDRA. Big wins for them in terms of being able to set up mixed materials/small molecule/biopolymer systems. SB – It does seem to make things more complex. I think you’re doing it right by taking the initiative. JW – Grant agencies can probably look at this as an experiment as to whether we can provide itneroperable software even though it’s inconvenient wrt our current incentives MT – SB – What does Vanderbilt aim to support? MT – MoSDeF efforts are basically targeted at their current collaborators. Some effort to get in contact with oil and gas. Limited uptake by other groups.
TG Some WBO stuff, ANI drama, picking typing work back up, CHO molecules/PhAlkEthOH dataset analysis Studying OpenFF-recharge wrt vsite fitting Analyzed coverage of Enamine REAL building blocks set Thinking about further automating fitting pipeline / QCA → FB target pipeline
DD Lots of work on benchmarking efforts with industry. Tons of help from DH. Had meeting with Industry partners. Yielded a good list of specifications for benchmarking project. Started discussion about ANI failures on QCF. Seems to be moving toward solutions. Will add ANI1 and ANI1-cxx to current datasets. Will increase maxiter on current ANI2 sets. Looking into memory usage on jobs. Will start by looking into GeomeTRIC. Code jam with TG and PB on WBO/torsion analysis. Will try to merge functionality into QCSubmit TG – My QC workers aren’t pulling down jobs. I’m not running XTB or ANI. DD – Which sets should we submit? Is there anything ready to go? JW – I haven’t heard about any sets coming together for submission for Sage TG – Enamine REAL building blocks could go it. DD – Could finish up submission for JM. Also protein fragments.
DD – I’ve been thinking about federated/distrubuted openFF-evaluator. SB, any thoughts? SB – It would be doable, but a big time commitment. First step would be to move data models over to Pydantic. DD – Is current refactor covering all of evaluator? SB – No, mostly just to handle gradient.s API remains constant. Just workflows change. DD – Good to know, so there isn’t a particularly good or bad time to start looking into this. SB – Big issue to switching to Pydantic is units. Pydantic Issue 935 is important to figuring out our strategy. MT+JW should also be involved in this discussion MT – When I was at VU, we picked unyt. Would be in favor of solving this up front and suing the same solution across whole stack TG – General pydantic question – What’s the correct pattern for including private instanced parameters into classes? I did something for this in QCSubmit but nobody is particularly happy.
JW openforcefield-1.3.0 and openforcefield 0.8.0 release OpenMM → Conda-forge migration stuff. Scopatz is leaving Quansight at the end ofthis week. Fired subcontractor who isn’t any more skilled than Jaime. Advisory board / conda commercial use Onboading Danny Cole and Chris Ringrose. Long-term refactor planning.
pAPRika system conversion functionality – How general should we aim to make it?
SB – Evaluator currently doesn’t aim to do much conversion, and just sticks with OpenMM. I’m waiting for Openff-system before I really aim for supporting different engines MT – Doesn’t seem to be a big need to expand or direct this development. We should let this handle what it handles and not worry about reusing it in the bigger ecosystem. JW – pAPRika may become a larger player in our FF benchmarking, and eventually fitting pipeline. SB – Right, the computational cost is currently too high to use in fitting, though we may be able to cut that down using reweighting. JW – I’ll re-invite him to these meetings so we can keep up with his developments.
MT – Pencilled in OFFTK 0.8.1 for second week of December. |