USER-INTEL package will generate an error if neighbor style nsq is used

LAMMPS LAMMPS Mailing List Mirror
1

Hello everyone,

I am trying to use the USER-INTEL package, but I found that it seems LAMMPS compiled with this package does not work if `neighbor 2.0 nsq` is used in the input file.

I have tested with the input file `in.intel.lj` which is located in the `src/USER-INTEL/TEST` folder. If the line `neighbor 0.3 bin` is replaced by `neighbor 2.0 nsq` and run it with `mpirun -np $NP lmp_intel_cpu_intelmpi -in in.intel.lj -sf intel`. It will generate an error `Requested neighbor pair method does not exist`. It seems the error happens when the neighbor lists are being initialized. I am not quite sure but it feels like a bug. The content of the log file is attached below. I also modified the input file `in.airebo` of the `example/airebo` folder in the same way, and the error is the same.

By the way, I found it is great that the USER-INTEL package can speed up my simulation about 3-4 times. But unfortunately it does not support pair style zbl, tersoff_zbl or reax/c. Is to support more pair styles included in the plan of the future development of this package?

The log file:

LAMMPS (3 Mar 2020)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:94)
using 1 OpenMP thread(s) per MPI task
Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
Created orthogonal box = (0 0 0) to (134.368 67.1838 67.1838)
7 by 2 by 2 MPI processor grid
Created 512000 atoms
create_atoms CPU = 0.00790715 secs

2

no, this is not a bug.
not really. the message simply means, that for the USER-INTEL package there is no neighbor list “npair” style that can do “nsq” style neighbor list searches. even though it is possibly to construct an alias to defer this to a non-threaded version or use the USER-OMP version (if available), this needs programming and that has not been done yet. there are plenty other pieces in LAMMPS that are missing in a similar fashion, that are being deferred until somebody comes up with a suitable use case. if your system is of a size where you may want to use an O(N**2) scaling neighbor list build method, it is likely that there is not as much to gain from USER-INTEL either.

out of curiosity: you have a system with > 500k atoms. can you tell us why you would want to use an O(N**2) scaling neighborlist construction method? are your simulations running too fast? :wink:

axel.

3

Hi Axel, thank you very much for your explanation! I am sorry I do not know very much about the neighbor list build algorithm. I just want to report the possible bugs, it is good to hear that this is not a big issue.

I would never think my simulation runs too fast. I hope they can run to the macroscopic scale. :slight_smile: My initial system is a monolayer graphene, it consists of about 10K atoms. I used the in.intel.lj as the example because I think it is much easier for others to repeat the problem. Your question helps me to understand better how to set the neighbor list. Unless I have a particular reason, I can always use neighbor style bin and the default settings. Is that right?

By the way, could you please tell me is USER-INTEL package going to support more pair styles in the coming future? Like pair style table, hybrid, reax and tersoff/zbl etc. It is awesome to speed up the simulation so dramatically.

Best Regards,

Wenqiang