[lammps-users] pair distance < table inner cutoff

I modified the top of the “some_pots” file to read:

N 299 R 2 16

The behavior does not change. Everything is specified to R, as far as I’m aware.

I’m not exactly sure what you mean with your second question, but I think this graph will answer it: http://shell.cas.usf.edu/~kmclaugh/out.jpg

So I was able to determine that the problem was due to using a low value for N in the “pair style” command in the input file. I misinterpreted the meaning of the value, thinking it meant the number of values in my table, rather than the number of values generated via interpolation. Still, I’m not really sure why this would cause such terrible behavior as shown in the image. So this brings me to another question:

If I use pair_style with N=100 and pair_write with N=10000, I believe I will generated 100 interpolated values, but then where do the remaining 9900 values come from?

So it turns out my interpretation of the problem was incorrect. I’ve used a debugger to monitor the functions in PairTable. Am I really the only person who has had a problem with this before?

First, here are parts of my input files, as a refresher to what I am doing.

3-d 2 metal surfaces coming in contact and then sliding

dimension 3
boundary p p p
units metal
atom_style atomic

read_data data

#pair potentials

pair_style table spline 299
pair_coeff 1 1 somemore_pots AlCo
pair_write 1 1 50000 r 1.16 16 alco AlCo

and here is “somemore_pots”

N 299

1 1.11127 17.4427 52.4443
2 1.16419 14.8643 45.5055
3 1.21711 12.6264 39.5015
4 1.27002 10.6838 34.2826
5 1.32294 8.99832 29.7286
6 1.37586 7.53732 25.7515
7 1.42878 6.27278 22.2678
8 1.4817 5.1805 19.2131

I don’t think the “read_data data” is relevant to the issue.

The number “299” in the file, can be increased to say 10000, and this fixes all the problems, for a reason that later became apparent. Note, however, that there are only 299 entries in my potential file.

First, here is the plot of my potential file (col. 2 vs 3) against the file that I wrote using the pair_write command.
and zoomed in to the problematic region

And to demonstrate that this is not just a spline problem, but also a problem which arises using “pair_style linear”
and zoomed in

So here are my findings using the debugger.

When spline is called, everything works as expected. yp1, ypn are the correct negative forces read from the file, y[] and x[] both match the file perfectly. y2[] is created and appears to be reasonable.

Now, splint is called from compute table, but it doesn’t use the expected values for x each time it is called. In fact, the only reason I can imagine it being called at this point (pre-simulation) would be for the pair write command, but this is not the case as I could then match the values for x being used with the points on my pair_write graphs (let’s call this the output potential). So anyhow, I made a list of the x’s being used the first 6 calls:

At first, I couldn’t make any sense of these numbers, but then looking closer at spline.pdf and spline2.pdf, I noticed that these are the points which are in agreement between my input potentials and my output potentials. In fact, if I use the same input file, and a different potential file, I see the same behavior. My input and output potentials agree primarily at the listed points.

I tried replacing spline with linear, and made the linear graphs above, which appears to suffer the same fate. My potentials (input and output), agree at the above specified points which are then connected with lines. Though I haven’t confirmed the following, my current thought is that the spline routine is being called once to estimate the values at some given points (listed above). Lammps then creates a table using these x values versus the splint calculated y values, then using a second pass of splint to connect these new dots, upon request of the simulation, or “pair_write”.

Additionally, I have tried specifying the inner and outer cutoff of my potential file, but that leads to even more unexpected garbage, which is even uncorrected by using a large n.

At this point, the easiest way to correct the problem is to use a very large value of n (though this increases seek times when the simulation requests a potential). I am going to try to modify the code to correct this behavior, though I fear my intervention may undermine some other usage of pair_style table.

It would be good to hear back from anyone with experience, thoughts, ideas or advise on this matter.

Keith McLaughlin

I'm not clear on what the problem is. If you use a small number of
points to tabulate a potential in a region that changes rapidly (i.e.
the core of your potential), then the splines will have wiggles as
your plots show. If you use a 10,000 in your input script
but only have 299 points in your tabulation file, then you haven't
really helped the problem, b/c the splines are fit to the values
in the tabulation file, then interpolated at the 10,000 pts.
So the 10K pts will just follow the wiggle faithfully.

I think what you want to do is use a large number of pts in the
tabulation file (at least in the region of fast variation), maybe spacing
them in rsq so that there are more of them at the core. That
should form a good set of splines. Then you can sample them
with any N you want in the input script.