2022-04-26 Protein-ligand benchmarks meeting notes

protein-ligand-benchmark - 0.3.0 milestone review, issue assistance, rebalance

• #20 - JChodera delegated to bobym - Will be done by end of week

  • JC – Next steps are to get compliant PDB files, then we’ll need to do some manual reviews of protonation and other error remediation

• #23

  • LD – I’ll get to this as soon as I’m done with benchmarking paper

  • DD – It’d be good to handle this sooner, maybe a target date within 2 weeks?

  • LD – Sounds good.

• #24

  • IA – I’m working on a workflow to find clashes (using cpptraj?) - The results of running this will change after #20 is completed since many clashes should be resolved

• #31

  • JC – We can dump some structures, but we’re going to start using a better structure for Jnk1, so that will be replaced but not removed.

• #30

  • IA – Should be done this afternoon

  • JW – Problem with pint defaulting to write out units as, for example Å instead of angstrom - OpenMM can’t read the former

  • JC – repr vs str? repr should be able to reinstantiate object from string

• #35

  • JC – Needs to be more prominent in the docs

  • MH – I have a PR open for this, need to add more

• #37

  • IA – Like #24, this will require the new Jnk1 structures, so we’re waiting on #20

• #40

  • DD – I just reached out to DHahn about getting the data from the historical runs at Janssen.

  • JC – Which format do we want to store these in?

  • JW – We could see about making this a manually-input network in our result store. So once we get the info from DHahn, we could format it by hand and store in with the other results from this project.

  • IA – What could be cool would also be using this as a starting point and then adding new edges

• #44

  • IP – I asked whether we should link to Zenodo, and how to handle contributors

  • JC – once we have cff files, we can ask contributors to add themselves?

  • MH – Do we want to make the recommended citation be the paper, or the zenodo?

  • DD – Wouldn’t it be circular if Zenodo read the citation.cff file, but the citation.cff pointed to zenodo?

  • MH – …

  • DD – Link to a particular release of the livecoms article?

  • JC – Since we may want to link to a particular protonation state, maybe we list BOTH the zenodo AND the LiveComs.

  • MH – That sounds good, but we need to default to a single one

  • JC – I think we need to link to both as citable resources.

  • (General) – We should have the citation.cff point to the latest Zenodo DOI, and make part of the release process be updating the citation.cff file

• IA – #49 - Protecting main branch?

  • JW – I’ve made you an admin on the repo, please go ahead and protect

  • DD – I’ll set branch protection.

• JC – Does anyone know the timeline for the protein ligand benchmark paper submission?

• LD – I’ll reach out to DHahn to answer this

OpenFE Settings Taxonomy - seeking feedback

• https://docs.google.com/document/d/10avT6qoE5tXjoCBvYDpP9vpI93FvhmgcAI9-0f-TElc/edit?usp=sharing

• JC – gave the https://try.openfree.energy a try; huge amount of work there, so kudos

  • have feedback on settings structure, since I think there is a different set of boundaries that should be drawn between groups of settings

  • want to focus on things we can actually standardize at a high level, then trickle down further to engine-specific settings

  • It’ll be hard to handle things like super specific thermostat/barostats/integrators that are only implemented in some engines. So we should be aware that those will exist and we want to keep the door open to handling them later.

  • Level 1: Anything that affects overall energy

  • Level 2: Anything that affects computed free energy differences between thermodynamic states

  • Level 3: Things that impact efficiency of sampling; these may be engine-specific, since they become technical statements about how an engine does things that may not be supported across others

• DD – I’d like us to iterate on this. Only RG can accept proposed changes on this doc.

• Everyone will review this doc and comment on items that need changing by tomorrow morning.

Protocol execution API - status update

• DD – RG and I met last week for a working session on the Transformation/AlchemicalNetwork PR. (GUFE #13). So the question was about the logic flow from the input to a compute worker. What we committed to doing was to go separately (link doc?).

  • Basically resolved to do something like how DASK does workflows. Will work on details and meet again Friday to reconcile conclusions.

  • Biggest questions now are “what goes where, when?” - Some things get fed into APIs, some things go directly to execution hosts

• JC – I’m interested to see what the API would look like - That would be the point of understanding/discussion where perses devs can start building interoperable components.

• IA – RG and I talked about this on Monday, had some thoughts about strategy, we’ll talk to you about this tomorrow.

work-breakdown-structure (WBS) for this project - seeking approval

• DN – https://docs.google.com/presentation/d/1pgkQ1zuJ6Kl_7Km0tam96nyzMhFJIkPxPuQiV4P7Qis/edit#slide=id.g11fb93507bf_2_194

• DD – Outstanding questions include whether we use/support pmx and/or lomap?

  • JC – pmx sets up certain calculations for GROMACS, but then there’s also a GROMACS API point that consumes that and does the FE calcs. So maybe we could interface with the GROMACS group at Groningen and ask to work together with them. But basically we’d start by only supporting OpenMM, and they could build into that soon.

  • IA – It’s somewhat likely that there will be personnel-time dedicated to interoperation between OpenFE and GROMACS in this area.

  • DD – We can update WBS to reflect this

  • JC – Should get Lucy Delemotte and Eric Lindahl involved once we begin working toward GROMCS interop - They’ll be initial points of technical contact.

  • JW – So let’s deprioritize the pmx point. What about Lomap?

  • IA – Lomap is ready to go

  • JC – We’ll need Lomap for this project.