Structure of AIREBO potential

Hi all,
Recently, I’m trying to implement the Interlayer Potential for Graphene/h‑BN Heterostructures (Leven, I.; Maaravi, T.; Azuri, I.; Kronik, L.; Hod, O. J Chem Theory Comput 2016, 12, 2896-905.) into LAMMPS.
Because this potential is dependent on the local normals, I need to include all pairs to calculate them, which is similar to many-body potentials. Since the geometry of graphene and hexagonal boron nitride (h-BN) is quite similar, I think a potential similar to airebo potential may work for this potential.
Basically, what I want to do is to replace the LJ potential in present AIREBO potential with the interlayer potential for Graphene/h‑BN. The difference is that there are four atom types in the new potential (C,H,B,N) instead of two (C and H). To my limited knowledge about AIREBO potential, I’m not sure whether the structure of AIREBO potential can be extended for more atoms types. Does any one know about it?
Thank you in advance!

Best,
Huang

Hi all,
Recently, I'm trying to implement the Interlayer Potential for
Graphene/h‑BN Heterostructures (Leven, I.; Maaravi, T.; Azuri, I.; Kronik,
L.; Hod, O. J Chem Theory Comput 2016, 12, 2896-905.) into LAMMPS.
Because this potential is dependent on the local normals, I need to
include all pairs to calculate them, which is similar to many-body
potentials. Since the geometry of graphene and hexagonal boron nitride
(h-BN) is quite similar, I think a potential similar to airebo potential
may work for this potential.
Basically, what I want to do is to replace the LJ potential in present
AIREBO potential with the interlayer potential for Graphene/h‑BN. The
difference is that there are four atom types in the new potential (C,H,B,N)
instead of two (C and H). To my limited knowledge about AIREBO potential,
I'm not sure whether the structure of AIREBO potential can be extended for
more atoms types. Does any one know about it?

​extending ​the airebo pair style to support more than 2 atom types is
going to be a major undertaking. there are plenty of places and data
structures where explicitly or implicitly is assumed, there are only 2 atom
types. if you go over the code line by line, it should become quite
obvious, but there are some constructs where it becomes visible only after
staring at the code for a while or wondering why certain constructs are the
way they are.

axel.

Hi Axel,
I see. Thanks!

Best,
Huang

Huang,

The potential by Leven et al is a pure two-body potential that only depends on pairwise interactions. It might be much easier for you to start from the lj/cut pair_style. You just need to change the repulsive and attractive terms. There is no need to start from the 4-body, over-complicated AIREBO potential for this implementation.

Ray

Hi Ray,
Thanks for your reply!
Actually, things are not so simple because one needs to calculate local normals for atom i and j when calculating the energy and force between them. To calculate the normals, a full neighbor list is required and all pairs should be included, so it’s quite similar to many-body potential although there is no interaction within one layer. This is the reason why I want to start with AIREBO potential:)
But it seems I need to find another way.

Best,
Huang

Hi Ray,
Thanks for your reply!
Actually, things are not so simple because one needs to calculate local
normals for atom i and j when calculating the energy and force between
them. To calculate the normals, a full neighbor list is required and all
pairs should be included, so it's quite similar to many-body potential
although there is no interaction within one layer. This is the reason why I
want to start with AIREBO potential:)

​to get a different neighbor list is just a matter of changing the neighbor
list request.
all you need to do is to provide your own init_style() function with the
required changes to the neighborlist request.​
from there on, the difference is small. in fact, a lj/cut pair style for a
full neighbor list, is simpler than the regular lj/cut.
i may have a copy lying around somewhere from some performance test on
multi-threaded force kernels.

axel.

Hi Axel,
Thanks for your suggestion! It would be great if you can send the copy to me if you can find it:)
Actually, I have tried to change the neighbor list request like follows:

int irequest = neighbor->request(this,instance_me);
neighbor->requests[irequest]->half = 0;
neighbor->requests[irequest]->full = 1;
neighbor->requests[irequest]->ghost = 1;

which is simiar to that in the pair_airebo.cpp.
But this would cause another difficulty, assume there are two layers of graphene, interact with the new potential, to calculate the normals, the neighbor list within one layer is needed. So after building the full neighbor list, I build a sublist from it (again similar to that in pair_airebo.cpp) to calculate the local normals. However, to calculate the interaction between two layers, only the neighbor list for atom in different layers is needed. As a result, I need to exclude the interaction between atoms within one layer. But I don’t find a good way to skip the unwanted pairs until I read pair_airebo.cpp more carefully. I think the way to skip the LJ interaction within one layer by introducing switching functions in airebo potential is smart, so I also want to skip the unwanted pairs in a similar way. This is the another reason why I ask this question.
Well, this is the whole story. Do you have any idea to skip the unwanted pairs smartly? Or maybe my solution to this pair style is not a good one?

Best,
Huang

Hi Axel,
Thanks for your suggestion! It would be great if you can send the copy to
me if you can find it:)

​are attached. they're just called lj/cut/full

please note, that this is set up to compute each pair twice and that
requires some tweaks to when calling Pair::ev_tally​() to account for that.

Actually, I have tried to change the neighbor list request like follows:
int irequest = neighbor->request(this,instance_me);
  neighbor->requests[irequest]->half = 0;
  neighbor->requests[irequest]->full = 1;
  neighbor->requests[irequest]->ghost = 1;
which is simiar to that in the pair_airebo.cpp.
But this would cause another difficulty, assume there are two layers of
graphene, interact with the new potential, to calculate the normals, the
neighbor list within one layer is needed. So after building the full
neighbor list, I build a sublist from it (again similar to that in
pair_airebo.cpp) to calculate the local normals. However, to calculate the
interaction between two layers, only the neighbor list for atom in
different layers is needed. As a result, I need to exclude the interaction
between atoms within one layer. But I don't find a good way to skip the
unwanted pairs until I read pair_airebo.cpp more carefully. I think the way
to skip the LJ interaction within one layer by introducing switching
functions in airebo potential is smart, so I also want to skip the unwanted
pairs in a similar way. This is the another reason why I ask this question.

​i would make it a condition, that atoms in different layers would have to
have different atom types. then you can skip unwanted pairs with a simple:
"if (itype != jtype) continue;​"

​axel.​

pair_lj_cut_full.cpp.gz (3.05 KB)

pair_lj_cut_full.h.gz (970 Bytes)

Hi Axel,
Thanks for your file and suggestion! I will first read your file carefully and then try to implement the new potential.

Best,
Huang