Currently for the NonEquilibriumCyclingProtocol, one can increase the cycling sampling performed by a single ProtocolDAG by increasing the num_cycles setting. This causes the ProtocolDAG to feature as many CycleUnits as num_cycles, which generally works well for most use cases, and allows for DAG-level parallelism on executors that support this.
However, for some execution contexts, such as Folding@Home, this approach restricts us to performing a single CycleUnit per Folding@Home work unit (WU), which can cause problems for both volunteers and the system as a whole if these execute too quickly. Increasing the equilibrium_steps and nonequilibrium_steps may increase sampling up to some limit, but still may result in too-short simulation times for practical Folding@Home use.
We propose adding a positive integer setting num_cycle_iterations or num_cycle_laps to the NonEquilibriumCyclingProtocol that defaults to 1 giving current behavior, but when set to 2 or more results in additional iterations of cycling within each CycleUnit on the ProtocolDAG. This will need to be encoded in the OpenMM integrator generated by the SetupUnit to work properly, I think.
Let's hold off on actioning this until we've performed more live testing with Folding@Home using @jchodera's sampling suggestions. We'll know more from that activity as to how vital this feature will be for us.
Currently for the
NonEquilibriumCyclingProtocol
, one can increase the cycling sampling performed by a singleProtocolDAG
by increasing thenum_cycles
setting. This causes theProtocolDAG
to feature as manyCycleUnit
s asnum_cycles
, which generally works well for most use cases, and allows for DAG-level parallelism on executors that support this.However, for some execution contexts, such as Folding@Home, this approach restricts us to performing a single
CycleUnit
per Folding@Home work unit (WU), which can cause problems for both volunteers and the system as a whole if these execute too quickly. Increasing theequilibrium_steps
andnonequilibrium_steps
may increase sampling up to some limit, but still may result in too-short simulation times for practical Folding@Home use.We propose adding a positive integer setting
num_cycle_iterations
ornum_cycle_laps
to theNonEquilibriumCyclingProtocol
that defaults to 1 giving current behavior, but when set to 2 or more results in additional iterations of cycling within eachCycleUnit
on theProtocolDAG
. This will need to be encoded in the OpenMMintegrator
generated by theSetupUnit
to work properly, I think.