Add `num_cycle_laps` setting to `NonEquilibriumCyclingProtocol`, allowing for additional NEQ iterations within each `CycleUnit`

[dotsdl]

In some contexts, such as Folding@Home use, it may make sense to perform additional nonequilibrium cycling sampling within each CycleUnit beyond just a single equil A -> A->B -> equil B -> B->A iteration. This would enable more nonequilibrium work values to be sampled from a single CycleUnit without merely extending the number of steps of each segment within the iteration.

To achieve this, could we add a num_cycle_laps settings parameter to NonEquilibriumCyclingSettings, and have this make the PeriodicNonequilibriumIntegrator produce multiple laps of its periodic iteration?

[IAlibay]

Is the intent here to have it do [A->B->A->B->A] (for N=2) or [A->B->A][A->B->A]?

I ask because one of these effectively acts as an "extend" and the other a "repeat".

[dotsdl]

@IAlibay I realize my notation might be a bit confusing, so adjusting it here. This is what I'm aiming for:

lap 0   : (equil A, neq A->B, equil B, neq B->A) 
lap 1   : (equil A, neq A->B, equil B, neq B->A)
...
lap n-1 : (equil A, neq A->B, equil B, neq B->A)

This differs from independent cycles in that these "laps" are sequential, with the next lap starting from coordinates where the last lap left off. You're right to point out that this would be equivalent to extension, but occurring internally to the ProtocolDAG.

I recognize that this may be less valuable for conventional compute, but for our use on Folding@Home in alchemiscale-fah this can help to increase the size of work units (which correspond 1:1 with CycleUnits) without just increasing equilibrium and nonequilibrium steps for a single cycle with dubious value. Work units that are too short can cause Folding@Home to thrash, and more work units spent for the same work can result in RUN/CLONE exhaustion within a FAH PROJECT, which we want to reduce where possible.

[ijpulidos]

If I'm understing this correctly, would just wrapping the cycle in a loop for num_cycles_laps inside the CycleUnit accomplish this?

[ijpulidos]

Ah no, it wouldn't, because of the starting/ending configurations. You are right in thinking that we would like to do this using the integrator.

[ijpulidos]

On a second thought, it could actually work with just wrapping the compute part on the CycleUnit in a loop, as long as we don't erase/overwrite the OpenMM context it should work. The challenge is then to extract useful information from each (works and trajectories) and compute the free energy estimates correctly, IMO.

[jameseastwood]

Please put this on the agenda for this week's Protocol Developers' meeting.

[dotsdl]

Ah no, it wouldn't, because of the starting/ending configurations. You are right in thinking that we would like to do this using the integrator.

Exactly, this is the tricky part in my view. I'm not immediately sure how to accomplish encoding all these laps in the integrator, but I assume it's possible? That's the only solution that could work on Folding@Home too, since we ship the integrator to be executed as a work unit.

[dotsdl]

From discussion in protocol devs, it may be the case that integrators already loop back on themselves when stepped through, which implies that multiple laps can be achieved by continuing to step forward. I will experiment with this within the feflow and alchemiscale-fah versions of the NonEquilibriumCyclingProtocol and report back here.

If this is the case, then num_cycle_laps as a setting would simply mean putting a loop in CycleUnit, where it would continue to walk through the integrator. For the alchemiscale-fah version, this would be a multiplier to the total number of steps that the openmm-core takes through the integrator, achieving the same effect.

I'll also check that our ResultUnit handles forward and reverse works correctly given the above.

[ijpulidos]

From the discussion earlier today. The integrator could already be supporting this by just calling the .steps method (thanks @IAlibay for noticing this). According to the docstring it should just work.