2022-06-07 Protein-ligand benchmarks meeting notes

protein-ligand-benchmark - 0.3.0 milestone review, mop-up

• DD – We’re close to done with this.

  • Last thing is PLB #52 review. Could I ask JC and IA to also review these?

    • JC – Can do

    • IA – Yes, may need to get to this EOW, delivering a workshop from tomorrow to Friday

  • move deadline to 2022.06.17 - seeking approval

    • JW + RG + JC approve

  • DD – This should be good, since merging this PR will resolve multiple issues

• DD – I wondered,that, if we’re changing the PDE2 source PDB structure, so we need to also update the reference field in the target.yml?

  • JC – The references are for the affinity data, right? The calculation field should list a specific PDB structure, but the measurement shouldn’t change.

  • JC – Another question is whether we should change the iridium fields now that the reference and alternate structures are switched.

    • DD ?

    • JC – Note that the iridium fields aren’t nested under reference or alternate, so in cases like this it’s unclear what we’d do if we had iridium data for both, or what the current iridium fields refer to.

• DD – restructure target.yml to have primary, secondary structure keys in 0.3.0

• DD – Should we try to track down a reference for the original structure?

  • JC – I don’t think so. Let’s just focus on documenting the PDB that we’ve selected.

  • DD – Should we remove any of the existing references?

    • JC – No

  • IA – We should somehow indicate that this PDB doesn’t correspond to the DOIs so that people don’t get confused in the future.

    • DD – Since I now have more time before the deadline I can do this cleanup.

fah-alchemy - current board status

• fah-alchemy : Phase 1 - MVP

• DD – I’m currently working on S3 version of results store. This is going to live in fah-alchemy, because I don’t want to weigh down GUFE with AWS-specific code.

  • DS – This could go in GUFE, could make it an optional dependency. Both projects will use S3, and some users might find it useful.

  • DD – RG, what do you think?

    • RG – This isn’t a binding decision, we can move it around if needed.

    • DD – I’ll put the S3 interface in GUFE then.

  • (Discussion about optional deps on conda-forge - Could use metapackages, have separate install instructions, etc)

• DD – FAH Executor implementation will be in fah-alchemy. Base executor class will be in GUFE.

• DD – Scheduler will be in fah-alchemy. This is because shedulers are really host-specific, there probably won’t be overlap between OpenFE’s needs and the F@H work server’s scheduler.

• DD – First protocol I’d like to work on on the fah-alchemy side is nonequilibrium cycling. This is largely already supported. JC does this sound good to you?

  • JC – Yes.

  • DD – We don’t want to use independent lambdas first for ASAP work, right?

    • JC – Yes.

• DD – SEcond protocol I’ll work on will be nonequilibrium switching since that will most closely match pmx which was used in previous openFF work.

MH : ProtocolSettings taxonomy working group update

• MH – Met with Matt and Richard last week; have a handle on what needs to go into potential

  • building a pydantic-based data model; will circulate to stakeholders next

• MH – I’ll plan to present my results at next week’s call.

IA : protein-ligand binding free energies - challenges for membrane proteins?

• IA – Just had a board meeting with OpenFE. Zara Sands brought up that we don’t have plans for membrane proteins. Is this something that we want to handle in this call/project?

  • DD – Is sands a gov board or ad board member?

    • IA – She was, b

• JC – tags are supported within protein-ligand-benchmark, demarcating different subsets of systems; could have one for a membrane protein set

• JW – from OpenFF perspective, wouldn’t divert time to membrane proteins

• JC – ASAP also will only be doing soluble proteins; wouldn’t touch membrane proteins if we don’t have to

• JW – depending on how components in play shake out over next few months, open to discussion on membrane proteins

• DD – Agree, I’d like to not divert effort to membrane proteins right now. Though having clean, tagged data never hurts and could catalyze initiation of efforts when we do decide for that.

• IA – To clarify, I wouldn’t argue that we should include membrane protein support in this project. Just figuring out how to handle this request/feedback.

• JW – This would be a good chance to improve CHARMM-GUI interop, since that’s already a high-traffic pathway in the field. It would be a big effort and we’d need to dedicate a lot of time and energy to it, but we could really improve the field.

  • JC – Agree, we should add this to the bucket of ideas for “possible interop engineer projects”

  • DD – How formal was this request to OpenFE?

    • IA + RG – Not formal. We don’t even have a mechanism to add this to our roadmap.

    • JC – The ASAP/F@H community doesn’t have membrane proteins as a high priority right now

    • JW – OpenFF won’t need membrane protein support for at least a year.