2022-03-22 Protein-ligand benchmarks meeting notes

“Should the FF go on edges or nodes?”

2022-03-18 JW | DD : FF on nodes vs. edges, pros and cons

Summary: So, when we talk about “where should the FF go in the graph”, we’re really talking about something bigger: “Where does all the logic that prepares a system for a simulation using a specific FF go in the graph?”. The options are:

• In the nodes (multiple nodes per “starting point”, each making assumptions for a different simulation engine/protocol):

  • Pro

    • System prep assumptions are extremely specific, makes it easier to compare effect of switching only FF and nothing else

  • Con

    • There will need to be additional information stored somewhere to say which nodes represent the same system, like labels on nodes saying “I’m actually one representation of this starting point” or special edges indicating “these nodes represent the same starting point”

• In the edges (DD and JW advocate this choice):

  • Pro

    • This truly measures the performance of an entire workflow

  • Con

    • This doesn’t allow someone to isolate the effects of choosing a particular FF, since assumptions about structure prep/conversion are also included in the edge definition

Proposed workflow draft, given data model for AlchemicalNetwork

1. Define AlchemicalNetwork.

2. Define Microstates as nodes.

3. Define desired Transformations, with Protocols, between Microstates as edges.

4. Define ExecutionStrategy with parameters, such as total simulation timesteps; the Executor will use this to allocate execution timesteps to each protocol iteratively.

5. Pass AlchemicalNetwork and ExecutionStrategy to Executor, which could be in-process or via an ExecutorClient to a separate Executor process.

   • Executor will apply ExecutionStrategy to AlchemicalNetwork to determine first set of Transformations to execute on available resources

   • Executor.setup will call Protocol.setup for each Transformation, operating on the Microstates;
     file artifacts for individual simulations corresponding to each Transformation.protocol will be organized specific to the Executor
     (e.g. the FAHExecutor will organize these according to the FAH work server's needs); generates Simulation objects for each Transformation.protocol

     • In other words, Executor has a persistent state store of some form

   • Executor.run will call run method for each Transformation.protocol, which in turn calls run method on each member Simulation; this will execute each in series if run in-process, with single-machine parallelism supported where possible

   • Executor can be run as a separate process in server mode, with interaction via ExecutorClient

     • client submits AlchemicalNetwork and ExecutionStrategy, and Executor dispatches Transformation.protocol.setup and Transformation.protocol.run jobs as appropriate to its available resources

       • for Transformation.protocols that generate many simulations, Simulation.run dispatched as separate jobs

       • need to discuss available Executors from perspective of OpenFE