Many-body DPD with SRP potential

Dear Users,

I am trying to simulate a polymer thin film using many-body DPD. I am using the LAMMPS version of 17Jan2018. I have carried out simulations of thin fluid (LJ) films using MDPD before. For a polymer chain of n beads, I have tried with both Fene bonds and SRP potential for the bonded interactions. The simulation failed due to the segmentation fault. In the following script, I have used the pair potential between particle type 2 and 1 as per the example of SRP potential (pair_style hybrid dpd 1.5 1.5 445352 srp 0.8 1 mid). It worked well with pair_style dpd, however, not working with pair_style mdpd. Is the segmentation fault due to the command “pair_coeff 1 2 none” in the case of mDPD? What could be other possible source of the segmentation error? I would appreciate any help. The input file is attached below.

The content of the input script is following:

polymers.lammpsdata (10.9 KB)

Dear Users,

I am trying to simulate a polymer thin film using many-body DPD. I am
using the LAMMPS version of 17Jan2018. I have carried out simulations of
thin fluid (LJ) films using MDPD before. For a polymer chain of n beads, I
have tried with both Fene bonds and SRP potential for the bonded
interactions. The simulation failed due to the segmentation fault. In the
following script, I have used the pair potential between particle type 2
and 1 as per the example of SRP potential (pair_style hybrid dpd 1.5 1.5
445352 srp 0.8 1 mid). It worked well with pair_style dpd, however, not
working with pair_style mdpd. Is the segmentation fault due to the command
"pair_coeff 1 2 none" in the case of mDPD? What could be other possible
source of the segmentation error?

​the segfault is due to not using the "mdpd" atom style, so that the
per-atom property "rho" is initialized. please see the gdb output below:

Program received signal SIGSEGV, Segmentation fault.
LAMMPS_NS::PairMDPD::compute (this=0x147fbe0, eflag=1,
    vflag=<value optimized out>) at ../pair_mdpd.cpp:122
122 rhoi = rho[i];
(gdb) print rho
$1 = (double *) 0x0
(gdb)

if you want to have bonds and use mdpd, you'd have to use a hybrid atom
style, e.g. hybrid bond mdpd and then also adjust your data file
accordingly.

axel.

Thank you very much Axel.

Debdip

Dear Axel and Users,

I am confused with the atom_style mdpd command. As per the manual, the atom description should have the following format: atom-ID atom-type x y z (read_data command). I found that the particles are described as following ( in the outputfile of a mdpd simulation from the examples, using atom_style mdpd):

1 1 0.0000000000000000e+00 -1.9655560456566725e+01 -7.4254339502585411e+00 -1.7471609294725978e+00 0 0 2

2 1 0.0000000000000000e+00 -1.8781979991830426e+01 -7.4254339502585411e+00 -1.7471609294725978e+00 0 0 3

3 1 0.0000000000000000e+00 -1.9218770224198575e+01 -7.4254339502585411e+00 -1.3103706971044484e+00 0 0 4

4 1 0.0000000000000000e+00 -1.7908399527094129e+01 -7.4254339502585411e+00 -1.7471609294725978e+00 0 0 5

.

.

.

14330 1 0.0000000000000000e+00 1.8345189759462276e+01 6.9886437178903913e+00 1.7471609294725978e+00 0 0 14331

14331 1 0.0000000000000000e+00 1.8781979991830426e+01 7.4254339502585411e+00 1.7471609294725978e+00 0 0 14332

14332 1 0.0000000000000000e+00 1.9218770224198575e+01 6.9886437178903913e+00 1.7471609294725978e+00 0 0 14333

14333 1 0.0000000000000000e+00 1.9655560456566725e+01 7.4254339502585411e+00 1.7471609294725978e+00 0 0 0

I could figure out that the first two columns (from left to right) are for atom-ID and atom-type respectively; 3-5 columns are the coordinates. What are the last four columns? In the description of the atom_style, for mdpd style, additional information about density is required. Are the numbers in the rightmost column represents the nearest particle? It would be great if you kindly clear my doubts.

Thank you very much.

Regards,

Debdip

Dear Axel and Users,

I am confused with the atom_style mdpd command. As per the manual, the
atom description should have the following format: *atom-ID atom-type x y
z *(read_data command). I found that the particles are described as
following ( in the outputfile of a mdpd simulation from the examples, using
atom_style mdpd):

1 1 0.0000000000000000e+00 -1.9655560456566725e+01 -7.4254339502585411e+00
-1.7471609294725978e+00 0 0 2

2 1 0.0000000000000000e+00 -1.8781979991830426e+01 -7.4254339502585411e+00
-1.7471609294725978e+00 0 0 3

3 1 0.0000000000000000e+00 -1.9218770224198575e+01 -7.4254339502585411e+00
-1.3103706971044484e+00 0 0 4

4 1 0.0000000000000000e+00 -1.7908399527094129e+01 -7.4254339502585411e+00
-1.7471609294725978e+00 0 0 5

.

.

.

14330 1 0.0000000000000000e+00 1.8345189759462276e+01
6.9886437178903913e+00 1.7471609294725978e+00 0 0 14331

14331 1 0.0000000000000000e+00 1.8781979991830426e+01
7.4254339502585411e+00 1.7471609294725978e+00 0 0 14332

14332 1 0.0000000000000000e+00 1.9218770224198575e+01
6.9886437178903913e+00 1.7471609294725978e+00 0 0 14333

14333 1 0.0000000000000000e+00 1.9655560456566725e+01
7.4254339502585411e+00 1.7471609294725978e+00 0 0 0

I could figure out that the first two columns (from left to right) are for
atom-ID and atom-type respectively; 3-5 columns are the coordinates. What
are the last four columns? In the description of the atom_style, for mdpd
style, additional information about density is required. Are the numbers in
the rightmost column represents the nearest particle? It would be great
if you kindly clear my doubts.

​the documentation is incorrect, and the code to both read and write data
files has a some bugs.​
​column 3 is the "rho" parameters (which is 0.0 at the beginning of a
simulation), 4-6 are coordinates and the last 3 are image flags, but due to
one of the bugs, the last column has corrupted data, those should all be 0
in most cases. the necessary changes are in an open pull request to be
added to LAMMPS for the next patch release.

you can see the commit with the bugfixes only here:

axel.​

Thank you, Axel.
I would like to inform you that there is an issue with write_data command as well. It may be due to the erroneous input file. However, the error is:

double free or corruption (out): 0x0000000001ded680 ***

Thanks again.

best regards,

Debdip

That’s likely one of the bugs I fixed.