Problem implementing custom EAM style between atoms of dissimilar types only

LAMMPS LAMMPS Mailing List Mirror
1

Hello,

I have created a custom EAM style for energy evaluation only. I have duplicated pair_eam.h/cpp to pair_eam_test.h/cpp and deactivated the force addition. Otherwise, pair_eam_test works just like pair_eam.

I am running into an error when trying to implement eam_test on only-dissimilar atom types (in this code 9-11, but not 9-9 or 11-11). The following details how I tried to implement and troubleshoot this, and where I got stuck. I was checking if there is a more straightforward way to go about doing this. Help is greatly appreciated.

There were no errors with the following code, where eam_test was defined on atom types 9-9:

pair_style hybrid/overlay eam eam_test lj/cut/coul/long 10.0 10.0
pair_coeff 11 11 eam Cu_u3.eam
pair_coeff 9 9 eam_test Cu_u3.eam

However, this is my desired input and resulting error:

pair_style hybrid/overlay eam eam_test lj/cut/coul/long 10.0 10.0
pair_coeff 11 11 eam Cu_u3.eam
pair_coeff 9 11 eam_test Cu_u3.eam
…
ERROR: Incorrect args for pair coefficients (…/pair_eam_test.cpp:406)
Last command: pair_coeff 9 11 eam_test Cu_u3.eam

I traced this to the following block in pair_eam_test.cpp and commented out the error:

int count = 0;
for (int i = ilo; i <= ihi; i++) {
for (int j = MAX(jlo,i); j <= jhi; j++) {
if (i == j) {
setflag[i][i] = 1;
map[i] = ifuncfl;
atom->set_mass(FLERR,i,funcfl[ifuncfl].mass);
count++;
}
scale[i][j] = 1.0;
}
}
//if (count == 0) error->all(FLERR,“Incorrect args for pair coefficients”);

I then tried to run the desired block of code again and got a new error:

pair_style hybrid/overlay eam eam_test lj/cut/coul/long 10.0 10.0
pair_coeff 11 11 eam Cu_u3.eam
pair_coeff 9 11 eam_error Cu_u3.eam
…
ERROR: Incorrect args for pair coefficients (…/pair_hybrid_overlay.cpp:102)
Last command: pair_coeff 9 11 eam_ecam Cu_u3.eam

I then commented out the following error from pair_hybrid_overlay.cpp:

int count = 0;
for (int i = ilo; i <= ihi; i++) {
for (int j = MAX(jlo,i); j <= jhi; j++) {
if (none) {
setflag[i][j] = 1;
nmap[i][j] = 0;
count++;
} else if (styles[m]->setflag[i][j]) {
int k;
for (k = 0; k < nmap[i][j]; k++)
if (map[i][j][k] == m) break;
if (k == nmap[i][j]) map[i][j][nmap[i][j]++] = m;
setflag[i][j] = 1;
count++;
}
}
}
//if (count == 0) error->all(FLERR,“Incorrect args for pair coefficients”);

This was the final error, which came after the run command, and where I finally got stuck.

ERROR: Pair hybrid sub-style is not used (…/pair_hybrid.cpp:488)
Last command: run 1000

Again, I was checking if there was a more straightforward way of going about this without messing up the structure of the source code. Thank you for any help,
Anne

2

Sorry, but what you are trying to do, makes no sense on a conceptual level.

As a many-body potential, you cannot separate out pair-wise additive contributions from unlike pairs. Please recall, that in EAM, you have to first collect the electron density contribution from all neighboring atoms to compute the embedding term and its derivative which becomes then part of the energy and force calculation on top of pairwise terms. so if you want to look at interactions between multiple atom types, this always has to be “inclusive”, i.e. you must look at 9-9, 9-11, and 11-11 together to have 9-11 interactions included, it is not possible via hybrid styles to single out unlike interactions. In general, one has to be very careful when using hybrid pair styles with EAM, since you may easily exclude contributions from the embedding, if used incorrectly.

Thus the check in the plain eam pair style to require the same atom type to be specified (the mixed terms are auto-generated in the non-hybrid version or when using type ranges, depend on the respective self-self info, and thus must not be explicitly specified). in all other eam variants, this is not even allowed, a single pair_coeff * * … statement is required and all the mixed terms are included in the potential file (which allows more flexibility in adjusting the mixed terms to better fit the actual interactions).

In short, those tests and error messages are in the code for a good reason, and commenting them out must lead to problems because you will get into an unexpected and thus bogus internal state.

axel.