If you have a version of ReaxFF with the non-bond interactions set to
zero, then the above script is correct. I think there are issues with
trying to do a kspace calculation in concert with pair hybrid:
"When using a long-range Coulombic solver (via the kspace_style
command) with a hybrid pair_style, one or more sub-styles will be of
the “long” variety, e.g. lj/cut/coul/long or buck/coul/long. You must
insure that the short-range Coulombic cutoff used by each of these
long pair styles is the same or else LAMMPS will generate an error."
while it may be possible to produce an input that LAMMPS will run, i would
claim, that the resulting simulation will be tainted and likely completely
bogus due to the long-range electrostatics charge equilibration.
ReaxFF doesn't have the screening of the short-range coulomb that coul/long
based potentials have, which will lead to double counting part of those
interactions. even when not using a long-range solver (i.e.
lj/cut/coul/cut), there is the problem that *all* potentials have to be
consistent with the charges *and* charge equilibration, which typical water
potentials are not (especially those usually used with long-range
electrostatics).
with manybody potentials like ReaxFF, the many-body part usually has to be
wholly contained, i.e. if you want to do C-H, you also have to do C-C, and
H-H. if you want to do, C-O, you also have to do C-C and O-O, thus if you
want to do C-H, and C-O with ReaxFF, you also *have* to do H-H, O-O, and
thus also O-H. that is a principal problem, you have to remember, that the
manybody interaction will also look at triples or quadruples of atoms that
are derived from those pairs.
so in my personal opinion the best choice here is to do the *entire* system
in ReaxFF. i don't see a way to incorporate long-range electrostatics
consistently, and having a coulomb interaction between graphene (with
ReaxFF) and water (with LJ + Coulomb) would also be inconsistent (water
would polarize graphene, but not the other way around, and your water
potential would not be parameterized to account for the charge fluctuations
in ReaxFF). so the only consistent hybrid model would be using plain
pair_style hybrid (not hybrid/overlay).
C-C with ReaxFF
C-O and C-H with lj/cut
O-O, H-H, O-H with lj/cut/coul/cut
but that doesn't look like it will have any significant advantage over
using ReaxFF for everything.
in summary, pair_style hybrid and hybrid/overlay offer many ways to shoot
yourself in the foot and a *lot* of care and consideration to get it right.
axel.