I try to use a ereaxff file designed with acks2, but it keeps generating errors like:
I attach a log file, can someone tell me how to solve this? Thanks a lot
However, it turned out that the fix makes the common case worse so it is still work in progress.
That said, your initial pressure looks a bit crazy. So perhaps you could try to improve your workflow. I notice that you are running the initial minimization without charge equilibration. Why? If the system goes into a bad state because of the initial charges starting at zero (the default), perhaps you need to “seed” them with some simple estimate (doesn’t have to be very accurate, just enough to break symmetries and direct the minimizer into the right direction).
As second possible issue is your initial geometry. Please check for close contacts. Remember that you may have close contacts through periodic bondaries that are not immediately visible. Sometimes a little adjustment of the box dimensions works wonders.
Even though you are keeping some atoms immobile, I would try to apply the charge equilbration to all atoms instead of just the mobile atoms. The fact that atoms are immobile does not keep them from interacting with the rest. If those immobile atoms remain at the default value of a zero charge, it would be simply wrong. Determining their bulk values from a bulk system calculation of that compound and then setting their initial values accordingly and not updating them later may be even more physically correct.
Sorry, what’s the exact meaning of “seed”? Can I just add a fix acks2/reaxff command before minimizer? Now I add acks2/reaxff with minimize command, and also change the initial geometry to have less molecules in the boundary, apply fix acks2 and fix nvt to all atoms, but the same warnings appear when I run it.
units real
atom_style charge
boundary p p p
lattice bcc 3.51
read_data novacuum2.lmp
pair_style reaxff NULL checkqeq no
pair_coeff * * older_ereaxff Li C O H
neighbor 4 bin
neigh_modify every 1 delay 0 check yes
region bot block INF INF INF INF 0.0 5.329 units box
group fbot region bot
region free block INF INF INF INF 5.329 INF units box
group free region free
timestep 0.1
In order to further debug your system and the ReaxFF parameterization, you should set up a serious of new calculations of simpler systems that have only one component each and be fully periodic bulk systems. If the same warnings and errors appear for one or more of these, you have some serious problems and we would need to have a closer look.
Otherwise, the problem would then be with your actual simulation setup and less so with the force field.
To be explicit – these minimisers are usually iterative and will do better given an initial guess for the charges in the system. So it would be good to read in physically plausible charges to start with, maybe partial charges from a suitable fixed charge force field.
Does LAMMPS support e-Reaxff developed by Prof. van Duin group? He replied that they don’t use e-Reaxff in LAMMPS. So this may be the problem of the compatibility of e-Reaxff in LAMMPS. However, I saw someone use e-Reaxff in LAMMPS, in their paper. Did they misuse the e-Reaxff in LAMMPS?
Without knowing what e-ReaxFF is, it’s hard to help you, but my first guess would be that LAMMPS does not support it (anything supported in the official code is documented in the official documentation).
Many modified versions of LAMMPS and unofficial add-ons exist, both online and offline; you should directly check with the authors (of the “e-ReaxFF in LAMMPS” paper).
EDIT: looking more carefully at your screenshots, it looks like they trained their ReaxFF parameters against the data of the e-ReaxFF paper – not necessarily that they used the e-ReaxFF method itself. Whether that is physically valid or not is a discussion about ReaxFF, not LAMMPS
