Pair_coeff with lj/cut/dipole/long and examples/documentation

I may be doing something incorrect here, but I was trying out the DIPOLE package just to check documentation vs. code (specifically the “long long” examples), and I get an error when I try one of the examples in pair_dipole.html. According to the documentation, this should work (unless I’m misreading something) with the DIPOLE package installed:

units lj
lattice sc 1.0
region simbox block 0 2 0 2 0 2
create_box 3 simbox
create_atoms 1 box
pair_style lj/cut/dipole/long 10.0 12.0
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0

(that’s the entire input file). However, I get an “incorrect args for pair coefficients” error from the 4.0 at the end of the line.

The documentation suggests that this should work:

"The following coefficients must be defined for each pair of atoms types via the pair_coeff command as in the examples above, or in the data file or restart files read by the read_data or read_restart commands, or by mixing as described below:

  • [epsilon] (energy units)
  • [sigma] (distance units)
  • cutoff1 (distance units)
  • cutoff2 (distance units)"

From the source code, however, it only checks for cutoff1, and if cutoff2 is present, it throws an error.

Is this supposed to work, or is it just a documentation error?

A similar error occurs for the next example, viz.,

pair_style lj/long/dipole/long long long 3.5 10.0
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0

This gives an “Only one cut-off allowed when requesting all long” error. I assume this is a documentation issue.

This is an oversight in the documentation. When you use a long-range Coulomb interaction, only the global Coulomb cutoff may be defined.

Yes, with a long-range solver for both, LJ^6 and Coulomb, you must have the same “long-range” cutoff so you can use the same FFT grid and KSpace settings for both.

It should also refuse the LJ cutoff in the second pair_coeff line for the same reason as the individual Coulomb cutoff is refused in the first case. However, the pair style was written by a person with a very idiosyncratic programming style, which makes it very difficult to alter without the risk of breaking some functionality.

docs should be corrected in PR #3485 now.