Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dotsdl opened this issue Dec 12, 2024 · 9 comments
Assignees

Comments

@dotsdl
Copy link
Member

dotsdl commented Dec 12, 2024

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
Copy link
Member

IAlibay commented Dec 12, 2024

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
Copy link
Member Author

dotsdl commented Dec 12, 2024

@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
Copy link
Contributor

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

@ijpulidos
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

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

@dotsdl
Copy link
Member Author

dotsdl commented Dec 16, 2024

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
Copy link
Member Author

dotsdl commented Dec 17, 2024

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants