Problem with NEMD simulation of rigid particles with LJ solvent and FENE chains

LAMMPS LAMMPS Mailing List Mirror
#1

Dear LAMMPS users:

I am running into a problem while simulating a NEMD shear using fix/deform with nvt/sllod. Currently using lammps 26Jan 2017 (what’s available on the cluster)

My system contains FENE polymer chains with LJ solvent particles and small planar rigid particles. During the shear process, I get the following lost atom error in the thermo output:

Step Temp c_usual E_pair TotEng Press Pxz

3247 0.79962262 0.76663426 -8.1017349 -0.78377635 -0.25579495 -0.42698142
3248 0.80109391 0.76801819 -8.1028895 -0.78260881 -0.25778403 -0.42926876
3249 0.80213932 0.76894776 -8.1038341 -0.78138719 -0.25546524 -0.49882361
ERROR: Lost atoms: original 28900 current 28899 (…/thermo.cpp:427)

Upon inspection, I realized that it was the rigid bodies that were being lost right when the flip happens. Based on suggestions from the lammps doc and the mailing list, I applied the nvt/sllod to the solvent+polymer chains with fix/deform for all particles (remap v).

Whats strange is that this problem happens in some configurations and not others at the same number of rigid bodies (thereby leading to repetition issues). Also, this error takes place at different time steps irrespective of the number of rigid bodies for different configurations. I suspect some rigid bodies at the edge or corner are not remaped during the flip. However, all the initial configurations are most likely fine as all of them equilibrates well for 26 million steps (LJ units) and had other tests performed on them.

I tried reducing the timestep, increasing communication cutoff, using a bigger system and lowering the shear strain rate but the problem still persists.

I’ve tried debugging for weeks; so I decided to post here. Any suggestions on how to address this issue of “lost atoms” is highly appreciated.

Thank you,
Shoumik
Stony Brook University, NY

#2

you are using a LAMMPS version that is over 3 years old. that means, that there is a non-zero chance, that this issue may have been resolved since.

if not, it would be required, that you construct a minimal(!) test case (as small as possible with as few atoms as possible) that can reliably reproduce the issue within a short time. that would have two benefits: a) you can test different settings and a new LAMMPS executable easily on a local machine (there are multiple ways to install LAMMPS without compiling yourself and compiling itself has become significantly easier since 3 years ago). b) it will be more likely, that somebody else will look into this and perhaps make a suggestion.

axel.