# Pair-coefficients over-riding for modified eam potential

Hi all,

I am trying to incorporate a new potential into Lammps which is a local-density dependent potential and is constructed on the same lines as the pair_style eam.
The very first thing I did was to modify this section of pair_eam.cpp :

int count = 0;
for (int i = ilo; i <= ihi; i++) {
for (int j = MAX(jlo,i); j <= jhi; j++) {
//if (i == j) {
setflag[i][j] = 1;
map[i] = ifuncfl;
printf("\n Map [%d] = %d\n", i, map[i]);
atom->set_mass(i,funcfl[ifuncfl].mass);
count++;
//}
}
}

As you can see, I commented out the check for i==j types so that (I believe) this can now be used for a general case of i != j. However, my work runs into scenarios where the potentials for 1,2 and 2,1 are different.

So, my question is this:

a ) Consider 2 atom types 1 and 2 and 4 different potential files P11.eam, P12.eam, P21.eam, P22.eam. I wish to achieve the following:

central atom type neighbour atom type potential file to be used

1 1 P11.eam
1 2 P12.eam
2 1 P21.eam
2 2 P22.eam

can I do this by writing the following:

pair_coeff 1 * P12.eam
pair_coeff 1 1 P11.eam
pair_coeff 2 * P21.eam
pair_coeff 2 2 P22.eam

because, from what I understand, when I set coeffs for (1,2) it automatically sets the same for (2,1) and vice-versa. So, in line 3 above both (2,1) and (1,2) are now set to read values from P21.eam and the original assignment for P12.eam is lost.

This brings me to :

b) Is there any way to get around this, not only for this specific potential that I am trying to design but for any other pair potential present in Lammps. In other words, if I want (1,2) and (2,1) to have different pair_coeffs, how do I do that ?

Thanks

Your request for having the 1-2 potential being different from the 2-1 interaction violates newton’s third law. Are you trying to derive a new kind of physics? For any given pair, how can you tell it is the former from the latter?

It sounds like you want something similar to pair_style eam/alloy

or eam/fs. Those allow a single (allow,fs) file to have multiple
tabulations in it, for different combinations of atom types (elements).

That might be a simpler starting point for you than changing pair_style eam.

Steve

Dear Axel,

I realize the violation of Newton’s laws. I should have framed my question better. When i set coeffs for (1,2) that puts equal n opposite forces for (2,1), which is fine and is how it should be. But since my potential is environment dependent (local-density), I would also like another set of coeffs for (2,1) that puts another set of (different) equal and opposite forces on 1 and 2. The net forces on 1 and 2 would this be the sum of these 2 separate contributions.

And, that’s something I don’t think I can do with the pair_style eam. Sure I can use the hybrid/overaly option but that only works for dissimilar pair styles, while all my pair styles are eam.

Dear Axel,

I realize the violation of Newton's laws. I should have framed my question
better. When i set coeffs for (1,2) that puts equal n opposite forces for
(2,1), which is fine and is how it should be. But since my potential is
environment dependent (local-density), I would also like another set of
coeffs for (2,1) that puts another set of (different) equal and opposite
forces on 1 and 2. The net forces on 1 and 2 would this be the sum of these
2 separate contributions.

i don't know how to express this any other way, but: ​that is a dumb idea.
with a capital D. it sloppy and confusing and bad programming style.
you have to turn this into a new pair style anyway, so just allocate and
manage more parameters than what you are currently using. problem solved
cleanly.

And, that's something I don't think I can do with the pair_style eam. Sure
I can use the hybrid/overaly option but that only works for dissimilar pair
styles, while all my pair styles are eam.

​that is an incorrect assessment. you *can* have multiple instances of the
same type of pair style with hybrid pair styles. now, whether using that is
a reasonable approach is a different question. the few pieces of
information that look reasonable strongly suggest that you write a proper
custom pair style.

please spend more time reading source code and try to do things "the LAMMPS
way" rather than adding ugly hacks. what you are currently doing may look
easier right now, but unless you are a proper genius (and who is?), it will
come back quickly to haunt you and you'll spend so much more time debugging
and hunting for hard to find bugs, that you will lose more time in the long
run.

axel.