Floppy bodies

[mphoward]

Hi All,

HOOMD 2 had the concept of a "floppy" body:

https://hoomd-blue.readthedocs.io/en/v2.9.7/module-hoomd-data.html?highlight=floppy#hoomd.data.particle_data_proxy.body

that you could use by assigning body tag <= -2 to particles. We used this feature to keep track of particles that were within the same bonded set (e.g., molecule, composite nanoparticle) and exclude interactions within these collections, while still integrating all the particle coordinates independently.

As far as I can tell, the floppy body still exists in HOOMD's backend code (MIN_FLOPPY define), but this concept is not documented at the Python level. I noticed this when I tried to use thermalize_particle_momenta with particles in floppy bodies, and they did not get a velocity assigned. I expected that they would because they are independent degrees of freedom.

I had two questions:

• Was the floppy body intentionally removed in HOOMD 3?
• If not, should thermalize_particle_momenta assign velocities to particles in floppy bodies?

Thanks!

Regards,
Mike

[joaander]

I wasn't aware that the floppy bodies code was ever publicly documented or used in a production setting. I intended to remove it in 3.0, but apparently did not. I'm not even certain that it was intentional to exclude neighbors between floppy bodies but otherwise treat them as free particles.

I find the use of MIN_FLOPPY throughout the code confusing. We have signed integers at the user level but use unsigned at the C++ level. Therefore, there are dozens of places in the code where we need to check < MIN_FLOPPY or >= MIN_FLOPPY. When a contributor needs to add code, it is not clear when or why they should use one other the other, especially as there is no clear definition of what a "floppy" body is.

I would prefer a more robust solution (i.e. custom particle properties #1533). That would solve many issues as I often get requests to add a molecule or residue tag to HOOMD-blue data structures. However, adding a new particle property is a very large project. I would support a minimal change to thermalizeParticleMomenta if you are OK continuing to rely on undocumented behavior.

[mphoward]

I wasn't aware that the floppy bodies code was ever publicly documented or used in a production setting. I intended to remove it in 3.0, but apparently did not. I'm not even certain that it was intentional to exclude neighbors between floppy bodies but otherwise treat them as free particles.

Yeah, the floppy bodies were sparsely documented. Although there was a hoomd.group.floppy() and this data structure, the meaning was hidden in a short note in the neighbor list documentation.

https://hoomd-blue.readthedocs.io/en/v2.9.7/module-md-nlist.html?highlight=floppy#md-nlist

A student found that one time, and it turned out to be convenient for what we needed.

I find the use of MIN_FLOPPY throughout the code confusing. We have signed integers at the user level but use unsigned at the C++ level. Therefore, there are dozens of places in the code where we need to check < MIN_FLOPPY or >= MIN_FLOPPY. When a contributor needs to add code, it is not clear when or why they should use one other the other, especially as there is no clear definition of what a "floppy" body is.

I would prefer a more robust solution (i.e. custom particle properties #1533). That would solve many issues as I often get requests to add a molecule or residue tag to HOOMD-blue data structures.

I agree, this type conversion is confusing, and it would be better to have a different data field if someone wants these types of exclusions. It also implicitly sets a max value on the body tag that nobody would ever reasonably reach if they started counting from 0 but could lead to surprising behavior.

However, adding a new particle property is a very large project. I would support a minimal change to thermalizeParticleMomenta if you are OK continuing to rely on undocumented behavior.

I will open a PR to use MIN_FLOPPY in thermalizeParticleMomenta as a quick fix for now. This can be reverted later if you remove the floppy bodies.