i modified the buck/coul/cut potential to implement a potential which has an added D/r^24 repulsive term and which is first shifted after truncation and then smoothened using a exponential smoothening function which has a length scale of gamma which is an added parameter i have introduced. The long range part of the interaction was modified to use the simple form wolf method referenced in the paper by Fennel. I wrote a simple lammps input file to test the shape of the potential with the analytical plot and it came out exact. The issue I am having is that when I have say 1200 atoms, when I run on one or two processors, it runs fine and gives reasonable results but when I increase the number of processors, I get the error as seen in the “Error” file attached. Can anyone point me towards what might be going wrong as the mathematical implementation of the potential seems to be okay.
I have also attached the potential file and its header file for reference.
Thanks in advance for any help.
Error.out (8.58 KB)
pair_CHIK_wolf.cpp (19 KB)
pair_CHIK_wolf.h (2.14 KB)
You have a segmentation fault (possibly more) and you need to debug it using one of the memory checkers, e.g., gdb or valgrind.
You have a segmentation fault (possibly more) and you need to debug it using
one of the memory checkers, e.g., gdb or valgrind.
Yep. (Or try starting again from scratch. It does not sound like the
modification you made was too complicated. See below.)
I wrote a simple lammps input file
to test the shape of the potential with the analytical plot and it came out
It's easy for that to happen. Using pair_style buck/coul/cut as an
example, I remember hearing that that "compute" input script commands
PairBuckCoulCut::single(). However the "run" input script command
invokes PairBuckCoulCut::compute(). It sounds like you implemented
"single()" correctly, but failed to modify one of these functions
correctly to account for the extra parameters in your formula:
"allocate()", "coeff()". The error could also be elsewhere
("compute()", "init_one()", "write/read_restart()",
Instead, since your potential is pairwise-additive and short-range,
why don't you try using pair_style table?
(hopefully the number of atom types is not too large, so you don't
have to define many tables.)
pair_style table might be slightly slower than your pair_style, but no
more than a factor of 2. You can combine it with other pair styles
using pair_style hybrid or pair_style hybrid/overlay.
I am trying not to use tables as I am starting of with two atom types but will be extending it to multicomponent systems. I’ll also be doing a parameter optimization after this works. So trying to avoid tables unless necessary.
To test the potential, i put two atoms in a box and increased distance by giving one of them a velocity, so that it invokes compute() and not single() as would happen if I use pair_write.
From the Valgrind errors, I feel I have not initialized something properly but I have not been able to pinpoint what exactly . The interesting thing though is that when i just have the two atom system, valgrind doesn’t give any errors on run. So I am trying to figure what I invoked in the former that hasn’t been invoked in the latter.
I would reconsider the use of a table in your case, as long as for your system the computing time is similar for both pair styles.
the multiple table creation with many different parameters can be overcome calling lammps as a library from other code that creates said tables on the fly. probably (just probably) you want this linking too in order to do the parameter optimization
I think I fixed the issue. There was a small error in the init_one() region which I feel was causing all the issues. I hadn’t spotted it for the life of me all the other times I had gone through the code. I’m seeing no errors on Valgrind as of now when i run. Just have to make sure the system is behaving physically as i want it to.
Thanks for all your help