Hi All,
Is there any way to make sure one atom type does not interact at all with another atom type using ReaxFF?
For example in a 2 element system where B doesn’t interact with itself, I thought it would look something like:
pair_coeff 1 2 ffield.txt A B
pair_coeff 1 1 ffield.txt A A
Thanks for any advice.
Shawn
Hi All,
Is there any way to make sure one atom type does not interact at all with
another atom type using ReaxFF?For example in a 2 element system where B doesn't interact with itself, I
thought it would look something like:pair_coeff 1 2 ffield.txt A B
pair_coeff 1 1 ffield.txt A A
reaxff is not a pairwise additive force field and thus pair_coeff
statements like those above are not permitted.
please note that when including atom types A and B with any manybody
potential, you do not only compute A-B, A-A, and B-B interactions, but also
are looking other n-tuples of atoms. so knocking out a specific pair of
types would result in a massively inconsistent set of forces, as the
pairwise neighbor lists are used to construct the other tuples. so the only
way to have a consistent set of force with a manybody potential would be to
remove *all* interactions containing one particular type of atoms, but even
that has limited applicability, as the interaction between the groups of
types must be a pairwise additive potential, and it usually only works
reasonably well, if the two "partitions" have a limited area of interaction
and are well separated, e.g. when using a diamond nanomachining tool
operating on a metal. reaxff is really an all-inclusive force field, where
even these kind of hybrid setups are not recommended an will result to
inconsistencies.
these issues have been discussed in detail repeatedly on this mailing list.
please look up those discussions, if the one above does not satisfy you.
axel.
Say you have a system with 5 atom types. You want to use
any manybody potential in LAMMPS for types 1,2,3.
And another manybody (or pair) potential for types 4,5.
And define pairwise interactions for 1/4 1/5 2/4 2/5 3/4 3/5.
You can do that with pair hybrid. For the two manybody
potentials (either could be ReaxFF), you do something like
pair_coeff * * many1 … 1 2 3 * *
pair_coeff * * many2 … * * * 4 5
then also define the 5 pairwise terms.
Whether that is a good model, particularly with ReaxFF,
is a different Q.
Steve
Thanks for your input and suggestions. Would the “neigh_modify exclude” option have the same issue when looking at n-tuples of atoms? Or does this act after the neighbor lists are generated?
pair_coeff * * ffield.txt A B
neigh_modify exclude type B B
Say you have a system with 5 atom types. You want to use
any manybody potential in LAMMPS for types 1,2,3.
And another manybody (or pair) potential for types 4,5.
And define pairwise interactions for 1/4 1/5 2/4 2/5 3/4 3/5.
You can do that with pair hybrid. For the two manybody
potentials (either could be ReaxFF), you do something like
pair_coeff * * many1 … 1 2 3 * *
pair_coeff * * many2 … * * * 4 5
then also define the 5 pairwise terms.
Whether that is a good model, particularly with ReaxFF,
is a different Q.
Steve
Thanks for your input and suggestions. Would the "neigh_modify exclude"
option have the same issue when looking at n-tuples of atoms? Or does this
act after the neighbor lists are generated?
the neighbor lists are only pairwise lists. if you exclude those pairs of
types they are gone and you will be missing some of the n-tuples. just do a
test and you should immediately see that all you're getting is crap.
let me repeat: reaxFF is not a pairwise additive potential. arbitrarily
removing _only_ specific pairwise interactions is a _very_ bad idea. full
stop.
only the kind of setup that steve outlined where you partition whole sets
of atom types _can_ work with manybody potentials (and the inter-partition
interactions _must_ be pair-wise additive in this scenario). yet with
reaxFF you would *still* get an inconsistent force field for most
combinations of potentials and most systems.
axel.
My $0.02 for what it’s worth
In reality what Shawn is trying to do is analogous to a QM/MM simulation where the code is designed to take into account the multiple interactions types between QM-QM, MM-MM and QM-MM atoms. However, he wants to replace the QM with REAX.
This is an idea that has been kicked around and even prototyped but, to the best of my knowledge, is not integrated into LAMMPS or any other available MD code. It’s a compelling idea and would be interesting to have this functionality but it just does not exist, yet.
Jim
James Kress Ph.D., President
The KressWorks® Foundation
An IRS Approved 501 ©(3) Charitable, Nonprofit Organization
“Engineering The Cure” ©
(248) 573-5499
Learn More and Donate At:
Website: http://www.kressworks.org
Facebook: https://www.facebook.com/KressWorks.Foundation/
Twitter: @KressWorksFnd
Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message.
2016-04-22 0:05 GMT+02:00 James Kress <[email protected]...>:
My $0.02 for what it’s worth
In reality what Shawn is trying to do is analogous to a QM/MM simulation
where the code is designed to take into account the multiple interactions
types between QM-QM, MM-MM and QM-MM atoms. However, he wants to replace
the QM with REAX.This is an idea that has been kicked around and even prototyped but, to
the best of my knowledge, is not integrated into LAMMPS or any other
available MD code. It’s a compelling idea and would be interesting to have
this functionality but it just does not exist, yet.
This is pretty much what pair hybrid does, though.
Kristof
2016-04-22 0:05 GMT+02:00 James Kress <[email protected]...>:
My $0.02 for what it’s worth
In reality what Shawn is trying to do is analogous to a QM/MM simulation
where the code is designed to take into account the multiple interactions
types between QM-QM, MM-MM and QM-MM atoms. However, he wants to replace
the QM with REAX.
i don't see that similarity. in a QM code you cannot just turn off
interactions in such a non-inclusive way either.
This is an idea that has been kicked around and even prototyped but, to
the best of my knowledge, is not integrated into LAMMPS or any other
available MD code. It’s a compelling idea and would be interesting to have
this functionality but it just does not exist, yet.This is pretty much what pair hybrid does, though.
pair hybrid has the problems, that you cannot have two different ways of
handling long-range electrostatic interactions. if your MM system would use
some form of coul/long, then you cannot partition the kspace interaction as
needed.
that said, it should be *extremely* straightforward to implement such a
reax/MM setup with the code in USER-QMMM and lib/qmmm, by adapting the
provided example frontend for quantum espresso's pw.x code with one that
calls LAMMPS with reax instead. this would then do a Morokuma-style ONIOM
mechanical coupling with a consistent treatment of electrostatics
(basically, you need to run 3 systems. A) the whole classical system "as
is", B) the selected reax subsystem as isolated system, C) the reax
subsystem with the conventional force field instead. then you do A - C + B
and bingo.
in my personal opinion, a QM/reax coupling would be even more compelling.
axel.
2016-04-22 0:05 GMT+02:00 James Kress <[email protected]...>:
This is an idea that has been kicked around and even prototyped but, to
the best of my knowledge, is not integrated into LAMMPS or any other
available MD code. It’s a compelling idea and would be interesting to have
this functionality but it just does not exist, yet.This is pretty much what pair hybrid does, though.
pair hybrid has the problems, that you cannot have two different ways of
handling long-range electrostatic interactions. if your MM system would use
some form of coul/long, then you cannot partition the kspace interaction as
needed.
Ah yes, that's a limitation.
that said, it should be *extremely* straightforward to implement such a
reax/MM setup with the code in USER-QMMM and lib/qmmm, by adapting the
provided example frontend for quantum espresso's pw.x code with one that
calls LAMMPS with reax instead. this would then do a Morokuma-style ONIOM
mechanical coupling with a consistent treatment of electrostatics
(basically, you need to run 3 systems. A) the whole classical system "as
is", B) the selected reax subsystem as isolated system, C) the reax
subsystem with the conventional force field instead. then you do A - C + B
and bingo.
in my personal opinion, a QM/reax coupling would be even more compelling.
This is something we considered some time ago, too (before the QM/MM
capabilities in LAMMPS existed), but we never followed through because
research interests shifted. I'm not sure what would be so particularly
interesting about QM/reax, though.
Kristof
that said, it should be *extremely* straightforward to implement such a
reax/MM setup with the code in USER-QMMM and lib/qmmm, by adapting the
provided example frontend for quantum espresso's pw.x code with one that
calls LAMMPS with reax instead. this would then do a Morokuma-style ONIOM
mechanical coupling with a consistent treatment of electrostatics
(basically, you need to run 3 systems. A) the whole classical system "as
is", B) the selected reax subsystem as isolated system, C) the reax
subsystem with the conventional force field instead. then you do A - C + B
and bingo.
in my personal opinion, a QM/reax coupling would be even more compelling.This is something we considered some time ago, too (before the QM/MM
capabilities in LAMMPS existed), but we never followed through because
research interests shifted. I'm not sure what would be so particularly
interesting about QM/reax, though.
because it doesn't suffer from two problems in QM/MM: 1) with reax you
don't have a fixed bond topology and the resulting exclusions, 2) you don't
have the "polarization asymmetry", i.e. that the MM system will polarize
the QM system, but not vice versa.
axel.
that said, it should be *extremely* straightforward to implement such a
reax/MM setup with the code in USER-QMMM and lib/qmmm, by adapting the
provided example frontend for quantum espresso's pw.x code with one that
calls LAMMPS with reax instead. this would then do a Morokuma-style ONIOM
mechanical coupling with a consistent treatment of electrostatics
(basically, you need to run 3 systems. A) the whole classical system "as
is", B) the selected reax subsystem as isolated system, C) the reax
subsystem with the conventional force field instead. then you do A - C + B
and bingo.
in my personal opinion, a QM/reax coupling would be even more compelling.This is something we considered some time ago, too (before the QM/MM
capabilities in LAMMPS existed), but we never followed through because
research interests shifted. I'm not sure what would be so particularly
interesting about QM/reax, though.because it doesn't suffer from two problems in QM/MM: 1) with reax you
don't have a fixed bond topology and the resulting exclusions, 2) you don't
have the "polarization asymmetry", i.e. that the MM system will polarize
the QM system, but not vice versa.
I see. That's true of course, although not per se limited to reax.
Kristof
i don’t see that similarity. in a QM code you cannot just turn off interactions in such a non-inclusive way either.
I probably didn’t describe what I’ve done well, but using capping atoms to properly terminate the QM bonds, making sure the capping atoms are invisible to the MM and then mapping the interactions between QM/MM, MM/MM and QM/QM atoms properly you recover the “correct” (to the limit you can within the QM/MM assumption) interactions. You just have to make sure all the combinations and permutations of interactions are properly accounted and the artificial constructs that are added are properly taken into account.
I modified PC-GAMESS to do this about a decade ago and it worked quite well.
that said, it should be extremely straightforward to implement such a reax/MM setup with the code in USER-QMMM and lib/qmmm, by adapting …
Since the concept, in the context of REAX, is to make things go faster, I believe REAX/MM would be the way to go. Using a polarizable force field for the MM part and including it in the charge equilibration process could eliminate the problem Axel mentioned about nonsymmetrical polarization.
Just an idea …
Jim
James Kress Ph.D., President
The KressWorks® Foundation
An IRS Approved 501 (c)(3) Charitable, Nonprofit Organization
“Engineering The Cure” ©
(248) 573-5499
Learn More and Donate At:
Website: http://www.kressworks.org
Facebook: https://www.facebook.com/KressWorks.Foundation/
Twitter: @KressWorksFnd
Confidentiality Notice | This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message.