SimTK: OpenMM: [#1965] Add support for changing the current integrator associated with an OpenMM Context object

Share
Follow	Project Follow publicly Follow privately Unfollow See followers (63) List Map More info

Trackers

Date:
2014-01-15 03:43

Priority:
3

State:
Open

Submitted by:
John Chodera (jchodera)

Assigned to:
Nobody (None)

Summary:
Add support for changing the current integrator associated with an OpenMM Context object

Detailed description
It would be useful to be able to change the Integrator associated with an OpenMM Context object. There are a number of use cases where one would like to do some simulation with integrator A (say, 500 steps of Langevin dynamics) followed by use of another integrator B (say, a few steps of Monte Carlo via CustomIntegrator), and then back to integrator A again (or some other integrator C). Doing this currently requires constantly creating/destroying Context objects---which incurs significant overhead---due to the limitation of having only one integrator associated with the Context at once. Rather than allowing multiple integrators to be associated with a Context (which would also ameliorate this issue), allowing the current integrator to be swapped might be simpler. The Context API could be extended with a function like Context::useIntegrator(Integrator newIntegrator) I don't know how difficult this would be under the hood, but it would have significant speed advantages for us, since we're in exactly the situation described above.
It would be useful to be able to change the Integrator associated with an OpenMM Context object. There are a number of use cases where one would like to do some simulation with integrator A (say, 500 steps of Langevin dynamics) followed by use of another integrator B (say, a few steps of Monte Carlo via CustomIntegrator), and then back to integrator A again (or some other integrator C). Doing this currently requires constantly creating/destroying Context objects---which incurs significant overhead---due to the limitation of having only one integrator associated with the Context at once. Rather than allowing multiple integrators to be associated with a Context (which would also ameliorate this issue), allowing the current integrator to be swapped might be simpler. The Context API could be extended with a function like Context::useIntegrator(Integrator newIntegrator) I don't know how difficult this would be under the hood, but it would have significant speed advantages for us, since we're in exactly the situation described above.

Comments (1)
Attachments
Changes

Add A Comment:

Message
Date: 2014-01-15 19:27 Sender: Peter Eastman In principle this would be straightforward, but in practice there may be a lot of corner cases to hunt down. The best approach might be a CompoundIntegrator class that lets you switch between a fixed list of Integrators you define in advance. That way we know all Integrators you'll be using at the beginning of the simulation, and they'll all get initialized at the same time.

No Changes Have Been Made to This Item