2022-10-18 Protein-ligand benchmarks meeting notes

Participants

  • @Irfan Alibay

  • Jenke Scheen

  • @Diego Nolasco (Deactivated)

  • @Iván Pulido

  • @Mike Henry

  • @David W.H. Swenson

  • @Richard Gowers

  • Levi Naden

  • @John Chodera

Goals

  • RG : MCSS Lomap implementation

    • IP : questions on status

  • DD : fah-alchemy - current board status

    • two weeks out from Nov. 1 deadline

    • fah-alchemy : Phase 1 - MVP

    • @David Dotson development effort now focused on FahAlchemyAPIServer, FahAlchemyClient, and FahAlchemyComputeServer

      • Currently implementing task queue system; FahAlchemyComputeService instances pull from this for work to do, and use it as the basis for pushing results back

      • Building out test suite for fah-alchemy; tests with Docker-based neo4j in CI now working

        • using openfe-benchmark networks while we work toward protein-ligand-benchmark 0.3.0

  • IA : protein-ligand-benchmark : blockers and priorities

  • IP : Nonequilibrium Cycling Protocol (perses#1066) update:

    • Still refactoring RelativeFEPSetup to accept single phases and optional receptor.

  • MH : ProtocolSettings taxonomy (gufe#37) update:

Discussion topics

Item

Notes

Item

Notes

MCSS Lomap

  • RG: currently working an alternate MCS approach for getting ligands out of RDKit; appears to give saner results than Lomap

    • JC : is this intended to take already-posed ligands?

      • or generating all possible atom mappings and score them? Using geometry?

    • RG: think API can support a generator of mappings; on scorers, not tweaking approach yet

      • this is something that F@H would be useful for us to explore

  • JC : would be useful for JS to get familiar with API for atom mappings

  • RG : Clara Crist has a paper out for atom mappings that indicates it’s not just a 2d problem; that inspired approach to treating it as a 3d problem

  • JC : would be worthwhile coordinating on this? we can take advantage of our collective expertise here and avoid duplicating effort

  • IA : would be value in this as a separate call

  • DD: gufe#35 just merged, features abstract base class for AtomMapping: https://github.com/OpenFreeEnergy/gufe/pull/35/files

  • RG : we also want to be able to handle protein mutation atom mappings with the same API, so collaborating here would be useful

  • DD : we’ll use next week’s slot for a detailed discussion on atom mappings, opportunities to coordinate effort

    • this is also an opportunity to establish buy-in on gufe data model from others

  • RG : on network generation, Mary Pittman has been jumping into network planning based on atom mapping

    • JC : could have separate chats for network planning, atom mapping

protein-ligand-benchmark

  • IA : can’t generate atom mappings properly due to squashed rings

    • Melissa is currently redocking; so far appears to address #81

    • DD : we’ll await her PR, then IA and DD will review

  • IA : on #68, won’t touch until we have new docked structures

  • IA : on #76: WIP, could use feedback from JC

  • IA : on #69, blocked by #81; can use Mapping.to_dict for serialization approach now that they are GufeTokenizables

  • DD: Including data in the python package, now that we don’t need/use LFS.

  • IP : in the future will be contributing data to this repo from Relay; what is the process for contributing?

    • JC : need a guide to contributing?

      • would probably want to re-dock using a standard procedure

      • homogeneity is useful, even if it currently requires a proprietary tool

  • DD : would like to use the Relay submission as a forcing function for building a guide to contributing; also, would like someone else to dock these as a way to test the guide

  • DD : may make sense to pursue a separate working group for protein-ligand-benchmark as a way to share the burden of advancing it, including preparation of new structures for those with access to Schrodinger tools

    • would spin out protein-ligand-benchmark development from this forum into one with identified stakeholders

    • would address concerns stakeholders (in particular OpenFE board) raised on developments without being looped in

Nonequilibrium cycling

  • IP : we are able to execute nonequilibrium cycling from gufe objects

    • do have to do some processing on perses side to get into appropriate form for OpenEye

    • JC : can you create a gist where you pin down where/if key information is being lost in going from SDF → RDKIT → OpenFF → OpenEye

    • IP: This should be okay from the gufe side of things, we need to see if there is some information lost along the way.

Action items

@David Dotson will put together a two-paragraph proposal for protein-ligand-benchmark working group for circulation to stakeholders; should state needs, including for driver
@David Dotson will prepare next week’s agenda with focus on atom mappings; aim is to coordinate activity and avoid duplication of effort
@Iván Pulido will write an example with the possible atom naming issue in the SmallMoleculeComponent for the NEQ Cycling Protocol

Decisions