2023-04-04 Protein-ligand benchmarks meeting notes

DD : sprint retrospective

• Review Done cards

  • what went well?

  • what didn’t?

  • what do we need to improve our approach?

• DD – We now have everything merged for release 0.1. Big thanks to HMO for getting things in place.

• DD – Alchemiscale 102 – HMO set up a mechanism to rerun tasks that are inactive.

• DD – Gufe 148 – Needed different patterns in executedag that we needed. RG finished this and merged a few hours ago.

  • RG – This was largely held up by a docstring formatting issue.

  • DD – When will this be in a release?

  • RG – By the end of the week.

• DD – Alchemiscale 150 – Pulled in tests for the above.

•  

DD : alchemiscale 0.1.0 release imminent

• architecture overview : https://drive.google.com/file/d/1ZA-zuqrhKSlYBEiAIqxwNaHXvgJdlOkT/view?usp=share_link

• alchemiscale 0.1.0 milestone

• coordination board : alchemiscale : Phase 1 - MVP

• updates on In Review, In Progress, and Available cards

  • DD – Alchemiscale 112 – Some final prerelease changes. Would love a review.

    • MH – I can review this.

    • DD – Thanks, I’ll also ping HMO and take whoever reviews first.

    •  

• No new sprint this week; will re-tool board for Phase 2 - User Feedback and Documentation

JW – openff-toolkit will have support for multi-component PDBs very soon (0.13 or 0.12.1); in the undetermined future, will also support custom substructures, which would open the door for support of other biopolymers, for example

• JC – we are actively working on RNA FFs, so definitely interested in this; espaloma FF

• JW – won’t have resources to pour into development of an RNA FF for this year ourselves

• RG – we can currently do this using the pdbinf tool; we go straight from RDKit → OpenMM currently

• JC – would avoid relying directly on OpenMM Topology long-term; the OpenFF Topology would be the better path long-term

•  

• JW – OpenFE can load from correctly-named residues quickly; OpenFF approach will almost always be slower due to its element graph matching; using

• RG – Our philosphy is that we should always read well-formatted PDB files, with correctly named residues

• JC – The chemical component dictionary won’t have everything that could possibly be part of a protein.

• RG – Users could augment the CCD with their new residues

• JW – This wouldn’t work for polymer people and materials scientists (and we need to keep the door open for them)

• MH – Yeah, coming from the non-biopolymer world, I’ve seen people use workflows that required atom names and just get really put off by hacking in solutions.

• RG – Ok, well generally we’re sticking with residue name matching and we’ll need to load up multi-component rdmols into a Topology.

• JW – Sounds good, I can give tips on how to do this loaidng quickly (I’ve just been dealing with this)

In review

• DD – Perses 1066 - IP how’s this going/

  • IP – I need to schedule meeting with JC and DD about this.

  • DD – I’m happy to help get you up to date on the changes in gufe/other underlying stuff

• IA – PLB 83 – Working on this, we still want to do comparison testing to perses.

• DD – Last PR going into alchemiscale 0.1 - … MH or HMO will do this

• JC – – perses 1128 – Made progress. There’s some problem with atom mapping now.

  • DD – Are they reversed?

    • JC – Maybe

  • JW – We updated molecule.remap to update the remapped atom's maps - So if a molecule originally contained atom_map={1:2}, and it’s remapped with a mapping containing {1:10}, then the final molecules will contain atom_map={10:2}

    • JC – Interesting, I’ll check into that.

  • JC – I’ll aim to ahve this done by Thursday, otherwise will hand off to IP/MH

• DD – Examplenotebooks 36

  • Rg – Waiting on the release we’re going ti amke, of gufe

  • DD – Can I take on some of this?

  • RG – Nope,we’re good

•  

•  

IA : protein-ligand-benchmark : establish new working group, or use this one?

• IA – potential new participants – Folks outside this working group want to contribute. Particularly MAria at OE want to help curate and contribute GPCR data. Also questions about maintenance - There’s a question from exscientia - Who are the responsible people for this?

• JC – Great question, we should get a group together to run this, potentially adjacent to this meeting. Could be good to start by looking into replacing schrodinger prep. So let’s convene a call. On our end, we could contribute folks to support this. I suppose there’s also interest from OFE.

  • IA – I’ll check with our board.

  • need a starting document to identify the working group; get commitments of resourcing from participants

• DD – Does it make sense to require that if folks want to be in the working group, they’ll also contribute resources?

  • JC – Yes, very much so. There could still be advisory folks but most of the meetings would be among the actual contributors.

• JC – Any volunteers?

  • IA – I couldn’t dedicate leadership-level energy for at least 6 months. Could open up invites on slack.

  • JC – Agree that opening invites is a good idea - Is there someone who could lead meeting organization/scheduling?

  • IP – I can do that.

  • JC – Cool - That would be great. Make it clear that we’re looking for people who can do at least 2 hours a week helping do maintenance and handling requests.

  • IP – Should I make these posts on free-energy-benchmarks?

  • DD – Yes, I think so. It’ll be good to make sure the benchmarking paper authors give some sort of response.

  • JS – IP, I can help lighten the load if needed.

• MH – Re: protein-prep tools - We’re taking about OE and Schrodinger - Are there open source tools we could use?

  • JC – There’s basically nothing. I was hoping that ML could really assist here but that hasn’t turned out to be the case. At least OE Spruce is free for academics.

  • DD – I wonder if OpenFold would be in a good spot to help with this.

    • JC – That would make a lot of sense. OR the rosetta folks may be able to help as well

    • IA – We’ve joked about OpenPrep before, but I think our partners would really be interested in this. Should we look down this avenue?

    • JC – Yes

    • IA – …

    • MH – Yeah, the companies supporting OpenFE would very likely all be interested in this.

    • DD – Agree, good opportunities for synergy here.

    • MH – Could pitch this at the OMSF symposium.

    • IA (chat) – we probably should have that conversation internally before we bring it openly in the workshop - there's a point to be made that we want to avoid a case where we further siphon money away from existing projects (centering on an existing project like openfold seems like a good idea)

  • JW – I’d used DockPrep to very limited success before - It does seem to be a more open solution, though the quality is a bit rough.

  •  

•  

•  

•  

JW + RG + IA – In person meeting planning

• We’ll push for it to be on day 1. Failing that, we’ll run it at the end of day 2 (starting 3:30/4 PM) - OFE will be running hands-on session in the AM to get EU folks involved.

  • RG – Will be looking for a lot of feedback during our hands-on sessions, like understanding compute platforms/workflow tools

• Ways to avoid splitting rooms on day 2?

  • OpenFE will have the “product announcement morning”, OpenFF will have the “product announcement afternoon”

• OFE stuff on day 3?

  • Looked at registrations, will be ~5 industry