Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] SPH/DPD packages incompatible with velocity remapping #3831

Open
jtclemm opened this issue Jun 20, 2023 · 1 comment
Open

[BUG] SPH/DPD packages incompatible with velocity remapping #3831

jtclemm opened this issue Jun 20, 2023 · 1 comment

Comments

@jtclemm
Copy link
Collaborator

jtclemm commented Jun 20, 2023

Summary

In several mesoscale packages (SPH, DPD-MESO, DPD-SMOOTH, and MACHDYN), an extrapolated velocity (avec->vest) is used to calculate pair interactions or implement a modified integration scheme. However, many fixes in these packages neglect the fact that the regular velocity array avec->v may be augmented in comm->forward_comm() and comm->borders() calls if there is velocity remapping and an atom crosses a PBC (e.g. in Lees Edwards boundaries or nonzero domain->h_rate arrays). This leads to nonsensical dynamics at the border.

This is demonstrated using the SPH package in the attached input script. Under simple shear, particle dynamics go haywire along the simulation border in the gradient direction. Using a patch drafted in this commit, 6f66bf6, no such behavior is seen and a clean linear velocity gradient develops.

Thanks to Phil Taylor (SNL) for identifying the problem.

LAMMPS Version and Platform

Development branch downloaded on 6/20/2023.

Expected Behavior

Using the above packages, velocity remapping should either a) produce correct dynamics at borders or b) trigger an error to prevent users from using a faulty combination of commands

Actual Behavior

Estimated/extrapolated velocities do not pick up the velocity remapping term leading to bogus forces at periodic borders.

Steps to Reproduce

In the attached input script, funky particle properties (e.g. rho) are seen at the interface after 5000 timesteps. For comparison, one can switch remap v to remap x (or used the linked patch) and the behavior disappears.

Further Information, Files, and Links

shear.lmp.txt

@jtclemm
Copy link
Collaborator Author

jtclemm commented Jun 20, 2023

While I believe the proposed patch should solve the problem, there might still be errors depending on when domain->pbc() could be called during a timestep and exactly when each package uses the atom->vest array.

Unless there is a better idea to solve this issue, I can extend the proposed patch to some other packages and look more closely at domain->pbc() calls to check for inconsistencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: High Priority Bugs
Development

No branches or pull requests

2 participants