reaxff modeling with LAMMPS

hello everyone

i need to use reaxff for simulating a structure with C/B/O/N atoms. and LAMMPS doesn’t have its force field file in its library. if it exists , where can i download it ?
thanks
ali

hello everyone

i need to use reaxff for simulating a structure with C/B/O/N atoms. and
LAMMPS doesn't have its force field file in its library. if it exists ,
where can i download it ?

please see the first "Note" in the pair style reax or reax/c documentation:

axel.

You’d have to search for such a force field in the Literature or contact Prof. Adri van Duin of Penn St. U.

Even if there is a ReaxFF force field containing C, B, O, and N elements, it does not necessarily mean it is suitable for a system/structure containing all of the above elements.

Ray

Take a look here:

HCONSB.ff: (H/C/O/N/S/B)

M.R. Weismiller, A.C.T. van Duin, J. Lee, and R.A. Yetter, ReaxFF Reactive Force Field Development and Applications for Molecular Dynamics Simulations of Ammonia Borane Dehydrogenation and Combustion J. Phys. Chem. A (2010), 114, 5485-5492.

The parameters in this forcefield were extended/improved by two other publications:

A.M. Kamat, A.C.T. van Duin, and A. Yakovlev Molecular Dynamics Simulations of Laser-Induced Incandescence of Soot Using an Extended ReaxFF Reactive Force Field. Journal of Physical Chemistry A (2010), 114, 12561-1257 http://dx.doi.org/10.1021/jp1080302

F.Castro-Marcano, A.M. Kamat, M.F. Russo, A.C.T. van Duin, and J.P. Mathews Combustion of an Illinois No. 6 Coal Char Simulated Using an Atomistic Char Representation and the ReaxFF Reactive Force Field. Combustion and Flame (2012), 159, 23273-1285 http://dx.doi.org/10.1016/j.combustflame.2011.10.022

The C/H/O parameters are the same as in the CHO forcefield, with added S/C, S/H and S/O descriptions. This force field was used in Castro et al, Combustion and Flame 2011

The Boron and Nitrogen parameters are based on (but not identical to) the parameters used in Weismiller et al, JPC-A 2010.

Jim

James Kress Ph.D., President

The KressWorks® Institute

An IRS Approved 501 ©(3) Charitable, Nonprofit Corporation

Engineering The Cure” ©

(248) 573-5499

Learn More and Donate At:

Website: http://www.kressworks.org

Facebook: https://www.facebook.com/KressWorks.Institute/

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.

1 Like

https://www.scm.com/doc/ReaxFF/Included_Forcefields.html

Check this site out. Helpful enough to search for the potentials and related papers.

That link has a long list of ReaxFF force fields that match

literature cites. Are the corresponding ff files openly available?

E.g. could a LAMMPS user get them somehow and use them with LAMMPS?

Thanks,

Steve

That link has a long list of ReaxFF force fields that match
literature cites. Are the corresponding ff files openly available?
E.g. could a LAMMPS user get them somehow and use them with LAMMPS?

The procedure would be to

1) Check out the cited reference and see if a force field file is inluded
as supporting information (true in most cases)
2) If not, ask Adri van Duin

BTW, the description of the FFs on the SCM site is not entirely correct:for
example, the "CHONSMgPNaTiClF" FF really doesn't work on all those elements
and their permutations: it's meant for Ti/O, and all the other elements are
just there in file but aren't optimized for interactions with Ti/O. You'll
always have to read the relevant papers to know what exactly works and what
doesn't.

Kristof

As far as I know, most of the papers listed in SCM contains the supporting info, and most of the supporting info contains the parameters. If the parameters are unavailable in supporting info, than we need to ask to the authors of the paper, or Dr van Duin.

And Kristof is correct, some info in SCM can be confusing - one need to read the papers carefully, and check the parameters in the supporting info.

Hello everyone,

Here is some material to reproduce an RDF/CDF bug with Reax/c. I set up a perfect diamond carbon structure with Reax/c, launched a “run 0” simulation (see Lammps input script in attached document – run on Lammps 17Nov16) to get the RDF/CDF of this initial configuration. The carbon coordination is 4.9, instead of expected 4.0 (see attached image).

To compare to another potential, i kept exactly the same strucure and replaced the Reax/c by a Lennard Jones (with unphysical parameter, but as i’m only interested in the initial configuration, that’s no matter). Now, the carbon coordination is correct and equals 4.0 (see attached image).

I also run my own RDF/CDF program on the dump file of this initial structure and again, i found carbon in coordination 4.0 (see attached image).

The spikes of the RDF are also higher with Reax/c than with LJ or my own program run on dump.xyz file.

Why the RDF/CDF are overestimated with Reax/c? A use of an incorrect neighbor list? Atom density incorrect?

Best regards,

Xavier Bidault

ReaxcRDFbug.in (1.01 KB)

ffield.reax (12.4 KB)

Reaxc_RDF_bug.png

Hello everyone,

Here is some material to reproduce an RDF/CDF bug with Reax/c. I set up a
perfect diamond carbon structure with Reax/c, launched a “run 0” simulation
(see Lammps input script in attached document – run on Lammps 17Nov16) to
get the RDF/CDF of this initial configuration. The carbon coordination is
4.9, instead of expected 4.0 (see attached image).

To compare to another potential, i kept exactly the same strucure and
replaced the Reax/c by a Lennard Jones (with unphysical parameter, but as
i’m only interested in the initial configuration, that’s no matter). Now,
the carbon coordination is correct and equals 4.0 (see attached image).

I also run my own RDF/CDF program on the dump file of this initial structure
and again, i found carbon in coordination 4.0 (see attached image).

The spikes of the RDF are also higher with Reax/c than with LJ or my own
program run on dump.xyz file.

Why the RDF/CDF are overestimated with Reax/c? A use of an incorrect
neighbor list? Atom density incorrect?

this is due to the way how normalization factors are computed in compute rdf.
the algorithm used does not account for neighbors of ghost atoms,
which are included in the neighbor list requested by reax/c but not in
the neighbor list requested by lj/cut.

axel

please try the following patch which should rectify this issue.

axel.

diff --git a/src/neighbor.cpp b/src/neighbor.cpp
index 59abc29..cbc8fe20 100644
--- a/src/neighbor.cpp
+++ b/src/neighbor.cpp
@@ -714,6 +714,8 @@ void Neighbor::init_pair()
       if (requests[i]->kokkos_host != requests[j]->kokkos_host) continue;

       if (requests[i]->ssa != requests[j]->ssa) continue;
+ // newton 2 and newton 0 both are newton off
+ if ((requests[i]->newton & 2) != (requests[j]->newton & 2)) continue;

       if (requests[i]->half && requests[j]->pair &&
           !requests[j]->skip && requests[j]->half && !requests[j]->copy)