Question about neighbor bin for tersoff/cuda potential

Dear lammps user,

Now I am running the MD simulations about single-layer graphene (100
nm length) under tension, in the simulations I use TERSOFF potential.
Firstly I set the neighbor definition as “neighbor 3.0 bin”, and I got
the error “ can not use neighbor bin –box size << cutoff” and I check
the lammps error section and follow the suggestion to use “neighbor
3.0 nsq”. Everything is perfect on CPU, but when I turn to GPU
platform, the error “Full_Nsq cuda neighbor list build is not
implemented anymore”. Appears. Which means that I need to use the
“bin” style and solve the problem “box size << cut off” if I want to
use the GPU function. The cut off radius of tersoff potential is set
to be default, and I tried to increase the box size in my data file,
but still fail to run the simulations.

Any comments?

Best

Ming Li

Here is my script about potential and neighbor definition

pair_style tersoff/cuda
pair_coeff * * SiC.tersoff C
neighbor 3.0 bin

the data file about the box size

       501500. atoms
       1 atom types
               -21. 2577. xlo xhi
               -24. 1081. ylo yhi
               -20. 20. zlo zhi
Atoms

a) You shouldn’t need to use a neighbor bin of 3 Angs. Try 1 (or less).

b) I don’t understand why you are getting that error. It should occur
when the box size (in some dimension) is much smaller than the
cutoff+skin, but yours isn’t.

Steve

And when I run the script below, I get no error about box size << cutoff.

You must be doing something else.

Steve

Dear Steve,

Thanks for your reply.

1, the default bin for metal unit is 2.0, I want to have a larger
neighbor list, this may waste computational source, but it is not
wrong, right? the small neighbour list may have unphysical result,
such as the cut-off radius of LJ potential.
2, the "xlo xhi,ylo yhi, zlo zhi" is set to be larger than the actual
box size by 20 angstrom. the minimum dimension is at the thickness
direction, but it is still larger than cut-off radius, I am also
confused why I get the error.

my script is as follows, which is quite simple, just run to get the
minimized shape instead of "minimization" command.

#define the problem
atom_style atomic
units metal
boundary s s s
  
read_data data.dat
mass * 12.0107

lattice sc 1
region 1 block INF 20 INF INF INF INF #left end
region 2 block 2633 INF INF INF INF INF #right end

group low region 1
group up region 2
group boundary union low up
group mobile subtract all boundary
# velocity setup
velocity mobile create 0.001 234567
velocity boundary set 0.0 0.0 0.0
#####define potential

pair_style tersoff/cuda
pair_coeff * * SiC.tersoff C
neighbor 3.0 bin
timestep 0.0005

#define NVT

compute new mobile temp
fix freeze boundary setforce 0.0 0.0 0.0
fix 1 mobile nvt temp 0.001 0.001 0.05 drag 0.2
fix 3 boundary nve
#thermal equilibrate
thermo_modify temp new
run 5000

#define restart file
restart 500000 restart.*.graphene

#run molecular dynamic simulation

dump 11 all atom 100000 tensile.*
dump_modify 11 format "%7d %3d %10.5e %10.5e %10.5e"
thermo_style custom step temp etotal pe ke ebond evdwl pzz
thermo 1000
thermo_modify temp new
run 50000000

Dear Steve,

Thanks for your reply.

1, the default bin for metal unit is 2.0, I want to have a larger
neighbor list, this may waste computational source, but it is not
wrong, right? the small neighbour list may have unphysical result,
such as the cut-off radius of LJ potential.
2, the "xlo xhi,ylo yhi, zlo zhi" is set to be larger than the actual
box size by 20 angstrom. the minimum dimension is at the thickness

this step is a biiiiiig mistake when using shrinkwrap boundary
conditions. on the first reneighbor all of those values will be reset
to the min/max coordinates in the same direction. so those should be
as close as possible to min/max. you can keep the box using "m"
boundaries, but all you'll do is create a load imbalance.

axel.

Dear Axel,

Thanks for your comments, it seems that the shrinkwrap style will
reset the min/max coordinate of the system since the atoms can go
beyond the boundary. the "fixed" and "m" may be reasonable. this make
senses, but in my simulations, the left and right ends are clamped,
the system is running with constrainted boundary, which means the
atoms can only move between left and right ends, can not go beyond
boundary. so do you think the "s" style will influence the reneighbor
operator when the motion of atoms are constrainted?

and also, you said that with "m" style, there will be fine without
error, but all I get is a load imbalance. my work is run the system to
obtained the energy favorable configuration, I can not follow "load
imbalance", could you say a little more about it?

Best

Ming Li

Dear Axel,

Thanks for your comments, it seems that the shrinkwrap style will
reset the min/max coordinate of the system since the atoms can go
beyond the boundary. the "fixed" and "m" may be reasonable. this make
senses, but in my simulations, the left and right ends are clamped,
the system is running with constrainted boundary, which means the
atoms can only move between left and right ends, can not go beyond
boundary. so do you think the "s" style will influence the reneighbor
operator when the motion of atoms are constrainted?

please re-read the documentation more carefully. if you use "s" the
size of the box will be adjusted to the extent of the atoms in that
direction. full stop. it doesn't care whether they can move or not. it
is up to you to choose the boundary conditions that are best for your
system, but "s" boundaries and your mentioning of "20 angstrom
additional space" make no sense together. none at all.

and also, you said that with "m" style, there will be fine without
error, but all I get is a load imbalance. my work is run the system to
obtained the energy favorable configuration, I can not follow "load
imbalance", could you say a little more about it?

load imbalance has nothing to do with the simulated material but with
"computational load". please read the LAMMPS paper and how LAMMPS is
parallelized with domain decomposition. if you have empty space, you
have processors that do nothing and processors that have to do more
work.

axel.

Dear Axel,

Thanks for your comments, I got it now.

Best

Ming Li

Also need the data file to run this. I still don’t
see anything in your script that should trigger the
error:

I got
the error “ can not use neighbor bin –box size << cutoff”

That is the error you are saying this script produces,
running on a CPU (with tersoff not tersoff/cuda) correct?

How many CPUs are you running it on?

Steve

Dear Steve,

I attached my data file and input script here, you can have a check.
It is a pity that I am out of office for international conference, I
can not access my GPU cluster to verify Axel and your suggestions, but
Axel’s suggestion sounds reasonable.

The error “box size << cutoff” is what I get for “bin” style with 48
cpus, then I use “nsq” which is not implemented with GPUs. Also
actually I use “AIREBO 1 0 0” potential definition in CPU platform,
when I use AIREBO in GPU, the job hangs at “uploading data”, Thus I
change the potential to “tersoff/cuda”. So is AIREBO potential OK for
GPU platform?

Best

Ming Li

Question.rar (1.83 MB)

Dear Steve,

Due to the limitation here, I upload my data file and input script
here http://www.adrive.com/public/xYEpvN/Question.rar. you can have a
check.
It is a pity that I am out of office for international conference, I
can not access my GPU cluster to verify Axel and your suggestions, but
Axel’s suggestion sounds reasonable.

The error “box size << cutoff” is what I get for “bin” style with 48
cpus, then I use “nsq” which is not implemented with GPUs. Also
actually I use “AIREBO 1 0 0” potential definition in CPU platform,
when I use AIREBO in GPU, the job hangs at “uploading data”, Thus I
change the potential to “tersoff/cuda”. So is AIREBO potential OK for
GPU platform?

Best

Ming Li

I can’t unrar a Windows file on my Linux box. Please

post it in a more generic format - e.g. a tar or gzip or bzip
file.

Steve

I can't unrar a Windows file on my Linux box. Please

while it is very annoying that people use compressed file archive
formats that are not commonly used on unix machines, you *can* unpack
them.

wget http://www.rarlab.com/rar/unrarsrc-5.1.6.tar.gz
tar -xzvvf unrarsrc-5.1.6.tar.gz
cd unrar
make

done.

Dear Steve,

sorry for my fault and the file with .zip format is avaialble now on
http://www.adrive.com/public/tWrezR/Question.zip

Best

Ming Li

Dear Steve and Axel,

today I tried the script with tersoff/cuda and fixed boundary style
suggested by Axel, and everything is OK without "bin size << cutoff"
error.

one more question, is there any way to accelerate the simulation with
AIREBO potential, I saw the "airebo/omp" developed by Axel, but it is
based on multi-threaded version, which may be not suitable for GPU
platform, is there any plan for developing "airebo/cuda" potential?

Best

Ming Li

is there any plan for developing “airebo/cuda” potential?

as far as I know, no one has done this. Someone can be

the first and write a paper on it.

Steve

is there any plan for developing "airebo/cuda" potential?

as far as I know, no one has done this. Someone can be
the first and write a paper on it.

please let me remind folks that the USER-CUDA package is effectively
unmaintained for quite a while now.
new developments should consider either contributing to either the GPU
or the KOKKOS package. well, KOKKOS may be a bit too experimental at
the moment, but since airebo is a complex potential, it may not be
like that by the time the accelerated pair style would be ready for
use.

axel.

it is pity that ther are no "airebo/cuda" or "airebo/gpu" potential, I
will try Axel's "airebo/omp" potential instead.
Best

Ming Li

it is pity that ther are no "airebo/cuda" or "airebo/gpu" potential, I
will try Axel's "airebo/omp" potential instead.

such pair styles usually exist because people that need them, learn
how to program such a thing and do it. people that do it mostly for
the fun of it are the exception.
lamenting about the lack of a feature, doesn't do much. often it even
discourages people to work on these.

in general such more complex potentials have a higher propensity for
acceleration than a simple potential like lj/cut. on top of that
airebo is a candidate for a significant refactoring due to its large
(near) redundancy, which makes it an idea candidate for using
templates.

like steve wrote, this is a great opportunity for somebody to have
his/her 15 minutes of fame. :wink:

axel.