I have been using pair_style table for some of the interactions in my simulation. As the manual suggested, I wrote the potential that LAMMPS reads from the table using the pair_write command. When I plot the energy/forces values obtained from pair_write with the original one from the table file, I see huge differences at low values of separation. The log file has a count of exactly how many of the values are mismatched (WARNING: 1501 of 5000 force values in table BP_OO are inconsistent with -dE/dr.).
I have tried increasing/decreasing the number of points at which the energy/force values are calculated which did not really help a lot.
Can you suggest anything that I should be trying?
You can always upload the files elsewhere (e.g. google drive, dropbox or similar) and provide a link to that place. The partial files only help a little.
I would also like to see your LAMMPS input file. There are also potential issues from that.
That input file contains the explanation. The potential energy and force must be different with pair_write since you are applying a different potential. You are using pair style hybrid/overlay to add a coulomb force to the interactions of all atoms. That will, of course, be included into the potential that pair_write will write to the table. If you remove the coul/cut pair style from the pair_style and pair_coeff commands, the table will be quite different.
The point you have made is absolutely correct. The pair_write file is writing out the energy/forces values for a combination from the Coulomb and Buck terms. I tried setting up the simulation with just the Buck potential and checked how the pre and post potential for O-O interaction look. I see almost negligible difference between the energy forces values at low separation computed with and without the Coulomb term (less than 10^-6 % ) for the O-O pair. This is because the correction function that I have applied to the Buck potential at low separation is a very strong repulsion that is much much higher than the O-O repulsion. However, at large distances, the Coulomb contribution is designed to be dominant over the Buck.
I still see the value mismatch warning (WARNING: 1501 of 5000 force values in table BP_OO are inconsistent with -dE/dr.) even when the Coul pair_style is removed.
The issue I see is that there is a huge discrepancy between LAMMPS written values and supplied tabulated values at low separation.
you have created a table with many data points down to a very short distance
LAMMPS uses an r**2 spacing table internally and then spline interpolation to redistribute the tabulated data
you do not provide the derivatives of the force at the edges of the table
The major issue is the r**2 spacing. In the internal table there are only two data points between the start of the table and a distance of 0.1. in combination with the crude approximation of the data at the edges, the first couple of spline coefficients are way off and thus also the data when writing out the potential back out. So the block of data that is has the “huge discrepancy” is derived from the same couple of “bad” coefficients.
FWIW, to confirm my explanation, I have created a modified pair style table that uses linear instead opf quadratic spacing internally and the bogus data at very low r is gone with that.
The good news is that atoms should not get this close for any reasonable use case, so the undesired energy and force values can be ignored.
Is there such a possibility that my potential made in LAMMPS before modelling is precomputed and saved into a table, and interactions are taken from this table? Ideally, I would like LAMPS to do this itself, rather than saving the table and then using pair_style table.
You can define a custom potential using pair style lepton in analytical form. No tables used.
But if you want to use a tabulated potential, you must use pair style table.
You can generate this table from LAMMPS using the pair_write command and if you use suitable settings (rsq style and same number of table entries) pair style table will import this table ‘as is’ and not re-interpolate the data.