Too many atom sorting bins

If there are still other users who are running into this error at the
beginning of the simulation (at the first time step), then here is a
solution:

I assume that you are starting off with a large simulation box, and a
small distance cutoff.

Anyway, to avoid getting. "Too many atom sorting bins", you must
(also) use the "atom_modify sort Nfreq binsize" command:

http://lammps.sandia.gov/doc/atom_modify.html

There is some confusion because a different "binsize" is also
controlled by this command:

http://lammps.sandia.gov/doc/neigh_modify.html
...and you probably need to specify the binsize this way too
(otherwise you will create too many bins and this can crash your
computer or slow down your simulation).

The two commands control different variables:
atom.userbinsize
neighbor.binsize_user

And the "Too many atom sorting bins" is only triggered when the
boundary box is too big and atom.userbinsize is not specified.
This error message is only generated at the beginning of the
simulation ( Atom::setup_sort_bins(), atom.cpp:1700, in the 2014-7-29
version of LAMMPS.)

It might be helpful to mention this in the documentation for this
error message at:

http://lammps.sandia.gov/doc/Section_errors.html#err_3

     ------ test case ------

I attached an example using a boundary box size of 2000^3, a pair
cutoff of 1.0, and these commands:

neigh_modify binsize 5.0
atom_modify sort 100 5.0

This runs without error. But if you comment out the second command
"atom_modify sort 5 5.0", you get the "Too many atom sorting bins"
error message, which I think happens during the first step of
minimization.

  ---- more realistic scenarios ----

    If you're curious, we run into this problem when simulating
extremely long self-avoiding-chains (random-walks) of length 10000 or
more. The input files for these simulations are too large to post
here. I realize these extremely sparse, non-uniform
semi-coarse-grained simulations might not be a good fit for LAMMPS,
but sometimes we need to run them, and LAMMPS works well enough for
our purposes. I suspect if other people are running into this error,
they might be doing something similar.

run.in (570 Bytes)

system.data (1.34 KB)