Individual updates | DN Short one this week - Brazil lost their world cup game JW, LW, and I agreed that we won’t have the all-hands meeting in Dec. But we’d like folks to put up a few sentences of updates on Slack. We’ll have the governing board meeting next week, then the ad board meeting the week after that. So I think I’m starting a new procedure before I start the agenda for those meetings. Do you have anything to add to the ad board/gov board agendas? Happy to hear topics now or via DM. I’m writing a blog post for the website, it’s been really difficult since we use the passive voice in Brazil. DM reviewed my blog post and provided feedback. I got the idea to do one post a day on linkedin and twitter to improve our reach and be more active in the community. So I’d be happy to source topics/posts from you guys.
MT Slow few weeks - Working on supporting non-12-6 potentials in Interchange. There’s not a super robust+general plugin system right now, but I figure it will be handy to support the alternative nonbonded forms that JHorton is working on. So we won’t have a super general plugin system for the forseeable future, and this will be openmm-only for the forseeable future. Lots of small code cleanups/reliability fixes in Interchange and Toolkit the past two weeks. Usually these come as the result of working on something else and noticing a problem/some part of the codebase that needs TLC. Making halting progress on benchmarking code, didn’t get much done the past two weeks but will work a bit more on this today.
DD Protein-ligand benchmarks / fah-alchemy worked out design for object store usage via APIs; now implementing decided that all result objects, including ProtocolDAGResults themselves, will be stored in object store avoids proliferation of nodes in graph database from DAG objects, as well as complicating our gufe <-> neo4j logic
made progress on first tutorial for users creating alchemical networks worked with Swenson, Henry on PRs related to CLI, deployment worked with Ivan, Henry on advancing perses NonEquilibriumCycling protocol; now uses gufe Settings for parameterization got Naden on board to work on a starter issue for domain permissions enforcement Would like to propose a name change for this project - it’s becoming clear that this is more general than just folding@home, so to have a broader base of appeal to users we might consider something clearer. DN, I’d expect this to be something that OpenFE can reach for when their users want a compute manager. DN – That would make sense, this is more general than F@H. DD – Right, this can run on more than just F@H, instead it could run entirely on something like a local cluster or cloud compute. Trying to work closely with OpenFE folks to make them feel a sense of ownership. JW – I’d approve a name change, I think this is a really good way to get broader buy-in. I think this should become an agenda item. MT – If you use Slack as a tool to solicit name suggesstions, absolutely set a time window/deadline for the discussion!
QCArchive no updates from on this front From what I recall, BP wants to push the rollout of the new ECF version to January. We should hear mroe tomorrow JW – Since BP will keep a mirror of the old archive up, I think i it’s OK if we don’t have QCSubmit up to date the day that BP makes the new release and updates the server. So we should just anticipate a gap in our ability to submit datasets when the update finally does come out, until we update QCSubmit.
JW Worked on hooking SMIRKS validation machinery back up, realized it will make FF loading 2-3 times slower. Now I’m considering just deleting it since bad SMIRKS will fail during parameter assignment. MT – Do you have a sense for how long you’ll take feedback on the “can I deprecate this” question? I didn’t see a time window on the slack post. JW – Good question. I want to get feedback from our science team (PB+LW+CC) - I’ll tag them on Slack.
Tried to fix AM1 proton rearrangement thing, but the antechamber “single point” AM1 charges are very different from what I get from OE. Not sure what’s up there. Working with DN and LW to finalize partner survey and make roadmap update for the website. Worked on some other PR reviews, issue triage. Made a quick conf gen+minimization script for potential new partner company. Still struggling with how to communicate “you can use gasteiger charges and they’ll be fast, but you can’t call them Sage” MT and I talked with LPW about ForceBalance updates and PRs that need attention. We have different philosophies around updates+deployment+stability. LPW offered to let us guide his attention to important PRs in the future. MT – I’m not optimistic about this working in the future. I’ve put a lot of time into opening PRs that haven’t been reviewed this year. DD – Would it help to document our position and these cases so that we can justify a decision later? MT – I could write up a list of cases. (General) – Who could we escalate this to? JW – If we escalate this to governing board, I think DM will ask us to talk to LPW more. So we should do that before we take their attention. DD – … MT – I’m not optimistic that we’ll get useful cooperation from LPW - not necessarily due to malice but rather philosophy. Also I draw a hard line at supporting python 2 compatibility. JW – I think we can try to get LPW involved again and make it a postive experience for him DD – Could be good to give that a try MT – I really don’t assess that this will work out in the long run. We have a great deal of pain in our ecosystem from unmaintained upstreams and I don’t want this to be another. DD – Is there a path that could reduce the penalties for forking forcebalance? Like, can we get LPW’s approval to do this? MT – Remember that we don’t need permission to fork. If we forked it, we could remove a lot of the stuff that we don’t use, like the tinker interface. We could probably jettison about half the code. I also don’t see a fork as necessarily antagonistic. DD – We’d be taking on the burden of maintaining an OpenFF forcebalance, but we’d also get to remove a lot of the stuff we don’t want and reduce that maintenance burden. So that could be a better solution that the current state. MT – I understand that introducing a large new tool into our ecosystem introduces a large maintenance burden and support surface area. But in that scenario we’d have all the control to do the maintenance. Right now we can’t even do the maintenance - The “fix CI” PR has been open for months. DD – It would be different if we were getting other maintainer contributions, but we haven’t even had those in the past year. MT – So I totally understand that this would put more work on us in the short term, but in the longer term we’d end up doing better on best practices and following our aims. JW – I’d like to try the “talk” approach - If we could work together to craft the essential list: 1 - The Fix CI PR (where recharge and evaluator are not run, and they’re broken, and some tests will fail because of Toolkit 0.11 and maybe other dep updates) MT – Editable installs PR (though this would require changing the directory structure, might not be worth the time) PyMBAR PR 2 - Toolkit 0.11 support MT – We’ll need to update to actually run+pass the Evaluator and Recharge tests. The evaluator changes should be tractable The recharge changes will be hard, SB made some big changes just before he left and I can’t easily follow the,
3 – Release (this will unblock BespokeFit) 4 – Fix evaluator PR
JW will contact LPW with this list of requests/priorities
|