Support rigid bodies in MPCD

[mzbush]

Description

Rigid bodies are currently incompatible with MPCD collision methods because:

1. The collision method needs to read the velocities of constituent particles, but they are not currently set.
2. The collision method updates the velocity of constituent particles in a way that is inconsistent with rigid motion.

We should add support for rigid bodies to the collision methods.

Proposed solution

1. ForceComposite should set the velocity of constituent particles based on the linear and angular velocity of the rigid body when it sets their positions and orientations.

   • HOOMD's angular momentum quaternion can be used to compute the angular velocity in the body frame.

   • The body's angular velocity can be used to get constituent particle velocities in the body frame relative to the center-of-mass translation.

   • These velocities can then be rotated to the space frame and have the center-of-mass translational velocity added.

   • Question: should this always be done, or should it be opt in?

2. The CollisionMethod should store the net change in space-frame linear and angular momentum for each rigid body as a result of collisions on constituent particles.

   • The changes can be computed by the base class taking the difference in velocity of constituent particles before/after collision or by recording the change during each collision. The first option is more generic, but the second option is probably faster because it has less read/write transactions.

   • In MPI simulations, we will need to reduce these contributions onto the rank that owns the central particle, then broadcast the result.

   • These changes will be used to update the velocity and angular momentum of the central particle for the body, then reset the constituent velocities.

Additional context

No response

[joaander]

Point 1 is briefly discussed in #278. Note that implementing it with MPI will require communicating the ghost angular momentum so that all ghost constituents have the needed information to compute their velocity locally. For consistency with the rest of HOOMD-blue, the constituent velocities should always be set. I think there is a flags mechanism to avoid communicating angular momentum when it is not needed.

[mphoward]

This is a good point: DPD (#278) has a similar issue as MPCD, in that the momentum transferred to constituent particles needs to be passed to the central particle to enforce the rigid constraint. We should consider this when we design our solution for MPCD so that maybe the same code can also be used for DPD.

Our plan is to set the velocities of the constituent particles first (making sure it works CPU, GPU & MPI), then we'll figure out how to address the momentum transfer part.

[joaander]

DPD applies forces to the constituents which will then be transferred as a net force/torque to the central particle by the normal means. The problem with using DPD and rigid bodies is that the constituents do not have a velocity set and the DPD thermostat depends on the relative velocity of the particle pair. Unless I misunderstood your solution 1 would solve this by setting the constituent velocities.

[mphoward]

DPD applies forces to the constituents which will then be transferred as a net force/torque to the central particle by the normal means. ... Unless I misunderstood your solution 1 would solve this by setting the constituent velocities.

No, you are right! I had in my head that there was a separate path taken for the thermostatting part, but since everything is done as a force, simply setting the velocities beforehand should be sufficient. We can then take the optimal path for MPCD to transfer the momentum, which is not done using a force.