Hello again, and thanks for the answer.
The TB-SMA potential does not need a particular order in calculating the energies and the forces. It is not a complex potential, the main difference in complexity from a LJ is that the bounding energy for each atom is a sum of terms under a square root, and this implies that the calculation of the forces needs to be preceded by a loop where the square root term is calculated.
With “The code works” I meant that when calculation goes well the style that I wrote gives the same correct outputs (energy and forces) as my old standalone code.
can you explain a bit more what you mean by this?
With the “bin” style for calculating neighbours sometimes the neighbours of some atom are not considered: by plotting the lists of neighbours (the one that is stored in “list->firstneigh[i]”) and the position of atoms (to manually confront the distances) I found that some neighbours were ignored causing the forces and the energy to be calculated wrongly.This error gets reproduced identical if I restart a calculation with the same input file.
With the “nsq” style I didn’t get this error.
again, some more specific examples (e.g. what kind of pointers?) to underline what you are observing and an explanation, why this is a problem would be very helpful.
I think I need to answer twice to this: in fact I get two different kind of errors.
At first the pointers that got corrupted(?) were the ones that should store the value of the parameters of the potential, created with the method “memory->create” and that are declared as "double** " in the header.
I made the class plot this table (in the “compute()” method) before starting each calculation:
nt &QSI[nt] QSI[nt] *(QSI[nt]+1)
0 0xf4f040 0xf4efc0 0
1 0xf4f048 0xf4efd0 1.818
few row later I get a SIGSEGV, this is the gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x00000000009c3e40 in LAMMPS_NS::PairSMATB::compute (this=0xf4e330, eflag=1, vflag=2)
125 qsiexpq = (QSI[itype][jtype]QSI[itype][jtype]) * exp(2.0q[itype][jtype]*(1.0 - dij/r0[itype][jtype]));
(gdb) p QSI[itype][jtype]
Cannot access memory at address 0x3d0a4ea2c1eae560
(gdb) p QSI[itype]
$1 = (double *) 0x3d0a4ea2c1eae558
(gdb) p &QSI[itype]
$2 = (double **) 0xf4f048
(gdb) p itype
$3 = 1
(gdb) p jtype
$4 = 1
and this don’t happen on the first atom but after some loop cycles.
Then in an attempt of making the code work I created another style, the parameters now are “double” variables, making the potential working only for one type of atoms and I got errors from various pieces of LAMMPS. for example gdb says:
ERROR on proc 0: Non-numeric atom coords - simulation unstable (src/domain.cpp:518)
Last command: minimize 1.0e-4 1.0e-6 100 1000