Hi all,
Is there any way to define joints/articulation between atoms/rigid bodies in Lammps? I read that “fix poems” only allows for spherical joints and I wonder if it is possible to simulate atoms in a way similar to multibody simulators do with rigid bodies by using revolute and prismatic joints? Or someway to create such joints manually in Lammps?
Best,
Deniz
As far as I can tell, fix poems is the only feature that comes close to what you are asking about.
And fix poems is very old code and thus on the verge of being removed from LAMMPS because it cannot be compiled (or corrected to be compiled) for modern compilers. Already it is producing a number of warnings that is growing with every new compiler version.
It would be nice if somebody would start a new package that tries to implement this kind of functionality and in a way that leaves room for future expansion. Of course, this is a significant chunk of work and would require some significant amount of complex math and some care with parallel programming since LAMMPS uses domain decomposition and handling joints that cross sub-domain boundaries can be challenging, especially for iterative solvers.
Thanks for the expalanation and the roadmap for a possible multibody dynamics Lammps package. I wonder if more effort would be required to connect Lammps (w/ granular package) to a recent multibody dynamic solver (Mujoco, Gazebo etc.) compared to building one in Lammps? There is an effort in this direction for Liggghts published recently: https://www.sciencedirect.com/science/article/pii/S003259102031024X
That is impossible to say up front. The POEMS package has two parts, the fix command and the library in lib/poems. So it is quite conceivable to have a lib/multibody folder with a wrapper around one of the libraries you mentioned and then a new fix for propagation.
As mentioned before, the challenge is in how to handle connected objects that extend over a large distance. Due to LAMMPS’ domain decomposition, only a limited number of atoms are “known” to each processor; some are “local” and some are “ghosts” from the neighboring subdomain. So either it must be required that the entire connected object is contained within this local plus ghost area (this is what fix rigid/small does) or the computation must be handled globally with a reduction and broadcast and thus significantly limiting parallel scaling (as it happens for fix rigid).