[user story] Run PMX-based P-L FE calculations using the same method as previous benchmarks

[j-wags]

In broad terms, what are you trying to do?

Automate a pipeline that's as similar as possible to @dfhahn's earlier benchmarks (section 2.2.3 of this link). Running protein-ligand free energy benchmarks are a requirement (or at least a very important "should" priority) for the release of Rosemary. Having a rapid and low-cost way to do this would greatly reduce the friction of testing new parameters and proposed FF modifications.

How do you believe using this project would help you to do this?

I envision that this project would provide an easy interface to ingest:

• a SMIRNOFF small molecule force field, identified either by name or full XML contents,
• a protein force field, identified by name,
• Chemical and/or atom-typed representations of the input molecules and the calculation parameters, either in the form of:
  • the topology files and scripts required as input to PMX to construct and run a network of calculations
  • the output of locally-prepared pmx preparation that can be submitted for immediate execution (potentially similar to #1)

Ideally, the structure inputs could be taken directly from https://github.com/openforcefield/protein-ligand-benchmark

What problems do you anticipate with using this project to achieve the above?

The PMX codebase is under continuous development and is somewhat fragmented, so it would be helpful to figure out pinning strategies to ensure that use of this interface really does just capture the change in FF performance, and not underlying changes in methodology.

Preparing protein structures for simulation is complex both technically and scientifically. The workflows that perform this preparation will likely undergo further development, and so a similar pinning strategy will be important to isolate the calculation results from changes other than those in the force fields.

[jchodera]

@j-wags : Do you need to exactly reproduce what was done previously if it's easy to consistently benchmark all generations of force field releases (and pre-releases) in parallel with a slightly different, more modern version of the codebase?

[dotsdl]

Raw notes from story review, shared here for visibility:

• this story articulates OpenFF's direct need for the system; benchmarking feedback loop for biomolecule forcefield
• transformations should be able to take a SMIRNOFF FF by name or full XML content
• protein force field, by name; presumably need to be able to compare new generations of OpenFF applied to proteins + ligands against OpenFF on ligand, another FF on protein
• not clear to me what the value-add of trying to support exactly what was done in a previous iteration of benchmarking if we are spending development time producing a new approach as an advancement to the old one; unclear yet to what level we will rely on PMX
• need clarity on how far down this path we really need to go
  • for simulation execution on F@H cores there are limits to how many simultaneous versions are tolerated by the organization in deployment, and these map to Gromacs / OpenMM versions
  • for the components of fah-alchemy, do we need to be able to call multiple openff-toolkit versions? These would each need their own associated environment, whether baked into e.g. a conda env or a Docker image; must cross process boundaries for this
  • should really ask the question why FF version isn't sufficient, with the openff-toolkit version not just stored in provenance in resulting calculations