hello
everyone
Today I would like to finish a model with the reaxff,but i meet some problems.
The types of atom element I use are Si\Al\O\Na\Ca,and the force field file is selected from the paper which doing the same simulation. But when I run it, I get a warning：
WARNING: Van der Waals parameters for element CA indicate inner wall+shielding, but earlier atoms indicate a different van der Waals method. This may cause division-by-zero errors. Keeping van der Waals setting for earlier atoms.
And element AL also have the problems.
Can you help me to solve it？
Thanks.
Please see previous discussions on the subject in the archives, e.g. inconsistent vdWaals-parameters Force field parameters for element CA - #2 by Kristof_Bal
Thank you for your answer, but I have Ca atoms and Al atoms in my atomic system. At the same time, the force field file I found has been applied to systems such as geopolymers, zeolite and calcium silicate hydrate.
So I’m wondering what the presence of this warning says about the problem and how it should be handled. Thank you so much.
Well, do the earlier atoms indicate a different van der Waals method? If they do, then you can’t use the inner wall+shielding van der Waals method for calcium, or can you? Has LAMMPS read any of the van der Waals parameters wrongly? And if you did want to use these different van der Waals methods together, would you really possibly encounter division-by-zero errors?
I have done zero ReaxFF simulations before, and yet the warning you listed makes enough sense to me that I can suggest the questions I have just asked.
“Another group wrote a paper that did XYZ in LAMMPS” does not actually guarantee that LAMMPS can actually do XYZ, or that XYZ is a good idea. That group may have modified something in their source code, or did something they forgot to state in the paper or described poorly in the paper, or plain made a mistake. The source code, and then the documentation, is the authoritative guide to what LAMMPS does or does not do; anything else, it is up to you to check with the paper authors.
I personally know of one code package which is cited to this day as being used alongside LAMMPS. Its source code on GitHub literally cannot compile without alteration, and yet not one paper which cites that package mentions that they changed the source code to make it work.
2 Likes
Do you mean that there is a problem with the force field file?
I guess the force field file states the van der Waals parameters so I guess the file is where the problem lies. Emphasis on I guess. You will have to be the one who works out where to look and what to do. 
thank you very much.
It would be easier for me to comment if you had uploaded the potential file, but I’m fairly certain that the issue occurs because some of the elements don’t possess parameters for the inner core repulsion. To be more precise, the parameters are equal to 0 and this is a problem, because the energy term looks like this:
E_{core}=e_{core}\mathrm{exp}(a_{core}[1-r_{ij}/r_{core})]
If two atoms are within a cutoff and at least one of them have the r_{core} parameter set to zero, the above expression will lead to a divide-by-zero error. This issue mostly occurs when two ReaxFF potential files are merged. You can use such a parametrization as long as there are only Coulomb and vdW interactions between elements from different potential files. Even then the accuracy of such model is arguable.
If you are certain that you still want to use such a merged potential file, you need to change the 30th atomic parameter (the 6th parameter from the 4th line) from 0 to 1 for each element where this parameter is equal to zero. Atomic parameters are the second section of the file and they start with the element name (e.g. Ca).
2 Likes
The comment in the potential file says it is for H/O/Si/Al. There is no mention of Ca or Na, which you are using. So your use of the potential file is not correct. As was discussed in the message from the mailing list archive that I had pointed out to you, potential files often contain parameters for atoms that were left over from a previous parameterization and thus are essentially garbage. It is a very bad habit of the force field parameter developers, but a habit that prevails and is understandable due to the structure of potential files which makes it convenient to replace parameters for elements but rather tedious to remove or add elements.
In other words, if your simulations would only use the elements H/O/Si/Al, there would be no warning. You would only get it for elements that have not been updated to match the others.
The 30th atomic parameter of CA is 1.4
I see what you mean, you mean that this is a problem left over by force occasions and development, so if I continue to use this force field file and ignore the warning, is it okay？
No.
But the element Al also has this problem.
The potential file looks like it has been created from at least two other files or some of the parameters were modified afterwards. You need to find the source publications for all the parameters and only then you can judge if the file is suitable for your simulation.
Sometimes researchers train only a subset of parameters and then such a merge of files is possible. For example, let’s say we have two files, one containing interactions between C/H/O/Al, another one with C/H/O/Ca.
If and only if:
- all global parameters,
- all atomic parameters for C/H/O,
- all bond, valence, dihedral, and hydrogen bond parameters for interactions between C, H, and O
are exactly the same in both files, then you can use the merged file for simulation of C/H/O/Ca/Al system.
Additionally, as I mentioned before, it would be the best, if there are no interactions between Ca and Al at all. This also means no valence and dihedral angles containing both elements. It may be permissible to have electrostatic and van der Waals interactions between Ca and Al, but nothing else. Even then an inquisitive reviewer (such as me, for example) would question the validity of such a simulation.
My previous comment about changing the 30th parameters from 0 to 1 still stands. It will prevent divide-by-zero errors without modifying any interactions between atoms.