search

glotzerlab / hoomd-blue

Molecular dynamics and Monte Carlo soft matter simulation on GPUs.
http://glotzerlab.engin.umich.edu/hoomd-blue
BSD 3-Clause "New" or "Revised" License
335 stars 130 forks source link

How-to: Continuously vary pair interaction parameters #1409

Closed rpcollanton closed 1 year ago

rpcollanton commented 2 years ago

Description

There are situations where it is desirable to ramp up energy prefactors during a simulation. For example, to gradually "turn on" a pair interaction.

Proposed solution

The user API would allow entering objects of hoomd.variant type as values in the parameter dicts for potentials.

Additional context

This could especially be valuable in relaxation or equilibration routines, such as that used by Kremer and Grest (1990).

rpcollanton commented 2 years ago

To be clear, I just started working with hoomd-blue, and as of yet have no clue what this would involve. Just thought I'd float the idea in case someone with more experience with the package wanted to chime in on its feasibility, and whether it would fit in with the overall design philosophy :)

joaander commented 2 years ago

There are technical challenges to implement variants for potential parameters. We store potential parameters in unified memory so that the values observed in Python and C++ are always in sync both on the CPU and GPU regardless of whether changes are made from C++ or Python.

Going to variants for parameters would require: 1) Breaking this synchronization and storing the variants in a 2nd matrix, updating the primary parameter matrix every time the force is evaluated. As this breaks the C++ -> Python side of the synchronization, it would require a major version bump. 2) Implement the code in such a way that constant parameters do not impact performance. It will be very expensive to update the parameter matrix every timestep, this cost must be avoided when parameters are not changing.

I don't see how the benefits of this outweigh the costs. With the synchronization promise we have, users can already implement custom updaters that change potential parameters. The Variant approach would only be a few lines less code for users and would be only marginally slower than a C++ evaluated variant. The cost to implementing this is very high. In addition to the considerations I list above, every EvaluatorPair class will need to be augmented with additional parameter types for the 2nd matrix, all of the pybind11::dict constructors and asDict will need to be rewritten and a 3rd method added that converts from one parameter type to the other.

We could instead add a "how to" section that describes how to write a custom updater that changes potential parameters. The implementation could even use Variant at the Python level.

rpcollanton commented 2 years ago

Thank you for your thoughtful analysis and informative response. From the information you provided, I concur with your assessment that the benefits do not outweigh the costs, especially given the importance of the synchronization promise! Plus, for this specific capability, a "how to" section on writing a custom updater would more than accomplish the goal, and extend well to additional capability users might be interested in.

joaander commented 2 years ago

Would you like to write that how to?

rpcollanton commented 2 years ago

I would like to, but cannot commit to completing it in a timely fashion right now due to some upcoming deadlines (next month or so) I am focusing on. If that's not an issue, then sure thing.

joaander commented 1 year ago

Contributions are welcome. A pull request should include a new how to guide in sphinx-doc/howto that demonstrates using a CustomUpdater to periodically change the parameters of a pair potential.