Quasi-2D in HPMC

[popolin522]

Description

In HPMC, enable 3D objects constrained to move in a plane, with out-of-plane rotations enabled.

Motivation

It's possible to do quasi-2D without out-of-plane rotations now, but having objects with out-of-plane rotations would be nice for studying interfacially confined objects (such as work from Escobedo group Thapar, V., T. Hanrath, and F. A. Escobedo. Soft Matter (2015)).

This topic has been raised many years ago (see #733). I am wondering whether there's any internal updates to this feature. If not, I can work on an implementation (or a similar approach) when I have time. Thanks!

Some testings I did

Just some current code behaviors I would like to share.

• Using hoomd.hpmc.external.Linear can "qualitatively" achieve quasi-2D, but it's at best a hack, and one needs to play around with the alpha parameter.
• Setting box to 2D [Lx,Ly, 0, 0,0,0] gives a nice quasi-2D system, but no out-of-plane rotations.

Proposed solution

Add a translate_move_dimensions parameter to HPMCIntegrator, as discussed in #733.

The parameter accepts integers 2 or 3, defaulting to None.

When set to 2 in a 3D simulation, the z-component of trial translation displacements is zeroed.

So now the API looks like

mc = hoomd.hpmc.integrate.ConvexPolyhedron()
mc.translate_move_dimensions = 2  # xy-only translations, full 3D rotations

Additional context

No response

[joaander]

I will gladly accept a pull request that implements this feature in HOOMD-blue. How should it behave when the box is 2D and translate_move_dimensions is set to 3? I think a runtime error is the most sensible option.

By the way, hoomd-rs (#2111) gives you full control over how trial moves are applied. Using hoomd-rs, you will be able to easily apply trial moves on a plane, along a line, constrained to the surface of a sphere, you can constrain one type of particles to a surface while other types are free, or any other behavior you can express in code. At the same time, you can independently control both the representation of the orientation and how the rotation trial moves are generated. In the above case (attempt to apply 3D trial moves to a 2D position), the user will get a compile error and can address the problem immediately rather than learning of the runtime error after a simulation job spends days in the HPC queue before running.

I hope to make hoomd-rs available open source in a few weeks.

[popolin522]

Cool. I will work on it.

How should it behave when the box is 2D and translate_move_dimensions is set to 3? I think a runtime error is the most sensible option.

runtime error sounds reasonable.

Rust with HOOMD? That's so cool!!!

I thought about whether I should still implement this if hoomd-rs is coming out, but I guess for this 2D system, one might want a large system size (for instance, determining whether it's continuous or weakly first order transition), so it's still worthwhile to do it (for GPU).

Thanks!