Domain too large for neighbor bins

Hi All,

So, I am basically testing out some systems level software and I want to be able to increase the number of atoms to quite large numbers so that I can really stress I/O. I am using some simple example input scripts from the examples folder.

I can see that increasing my “region” allows me to get a large number of atoms, however, it seems that some arrangements cause the code to throw errors, namely “Error: Domain too large for neighbor bins”.

I’ve attached the input script I’m using. It seems to me that the parameters I’m using for “region” cause this error (if I leave at the default, only 420 atoms get created).

I’d like to scale up to 10’s of millions of atoms.

Does anyone have any pointers on what I’m missing? Sorry in advance – I’m not an MD person and I’m just using LAMMPS as a use-case for system’s software on HPC machines. I don’t care much about the quality/usefulness of the LAMMPS results right now.

I’ve attached the input script.

Thanks so much!
Josh

in.indent (1.06 KB)

Hi All,
  So, I am basically testing out some systems level software and I want to
be able to increase the number of atoms to quite large numbers so that I can
really stress I/O. I am using some simple example input scripts from the
examples folder.

I can see that increasing my "region" allows me to get a large number of
atoms, however, it seems that some arrangements cause the code to throw
errors, namely "Error: Domain too large for neighbor bins".

I've attached the input script I'm using. It seems to me that the parameters
I'm using for "region" cause this error (if I leave at the default, only 420
atoms get created).

I'd like to scale up to 10's of millions of atoms.

then why on earth do you use an input that creates only a 2d system?
no person in his right mind would even want to scale this to millions
of atoms. if you look around the LAMMPS documentation, you see that
the benchmark inputs allow to do weak scaling tests with scaling the
system size to even billions of atoms through setting variables.
perhaps you should use one of those inputs. preferably the LJ
benchmark, since that has the least dependencies on the environment
and the fastest compute kernel.

Does anyone have any pointers on what I'm missing? Sorry in advance -- I'm
not an MD person and I'm just using LAMMPS as a use-case for system's
software on HPC machines. I don't care much about the quality/usefulness of
the LAMMPS results right now.

but you are *using* an MD code, so you either have to understand
enough of what an MD code does and why it does it, or else you are
going to spend immense amounts of time optimizing something that
nobody will ever do or have to deal with confusing errors like in this
case. the best way to deal with it, would be to find a local person,
that can fill you in, because experience shows that the "i don't know
what i am doing, please help me"-routine is getting old quickly and
soon you will be ignored (or worse). it just is not very idea to do
such things on your own.

axel.

1 Like

no person in his right mind would even want to scale this to millions
of atoms.

Why not? From an I/O perspective, this should be fine; it’s just streams of bytes. The software package is general enough to run a large number of simulations and analysis/viz toolkits (and it does). As a systems guy, like I said, I’m not concerned right now with generating useful MD results. LAMMPS is one of the simpler simulations from an I/O perspective (more so than things like the Maya/Cactus toolkit), so I figured it would be a reasonable starting point.

I understand that the simulation results I’m using won’t be meaningful - we’re still testing the middleware.

if you look around the LAMMPS documentation, you see that
the benchmark inputs allow to do weak scaling tests with scaling the
system size to even billions of atoms through setting variables.
perhaps you should use one of those inputs. preferably the LJ
benchmark, since that has the least dependencies on the environment
and the fastest compute kernel.

Excellent suggestion! I will have to check that out.

would be to find a local person,
that can fill you in, because experience shows that the “i don’t know
what i am doing, please help me”-routine is getting old quickly and
soon you will be ignored (or worse). it just is not very idea to do
such things on your own.

I understand the frustration. Unfortunately on my end, nobody local is familiar with this specific simulation… mostly weapons simulations, but for funding/political reasons, we’re not allowed to use those codes freely.

Perhaps I need to expand outside of the office.

Thanks!
Josh

no person in his right mind would even want to scale this to millions

of atoms.

Why not? From an I/O perspective, this should be fine; it's just streams of
bytes. The software package is general enough to run a large number of
simulations and analysis/viz toolkits (and it does). As a systems guy, like
I said, I'm not concerned right now with generating useful MD results.

yes, but you are - again - demonstrating the danger of dealing with a
software that you don't understand the principles of.

LAMMPS is one of the simpler simulations from an I/O perspective (more so
than things like the Maya/Cactus toolkit), so I figured it would be a
reasonable starting point.

i didn't talk about LAMMPS in general, but about using a 2d-model.
2d-models are good to figure out principles quickly, because the
number of particles is low and the number of pair interactions scales
O(N**2) with the cutoff and not O(N**3). but if you can afford to run
millions of particles, you would run a proper 3d-model. and for a
3d-model it is much easier to scale up to size.

I understand that the simulation results I'm using won't be meaningful -
we're still testing the middleware.

but you are testing your middleware with a very unusual workload. what
is the point of that?
you may not be aware of it, but i do have some experience in the kind
of work that you are trying to do and thus i am talking from
experience and not just making things up and give you a hard time for
no good reason.

yes, but you are - again - demonstrating the danger of dealing with a
software that you don’t understand the principles of.

No disagreement.

but if you can afford to run
millions of particles, you would run a proper 3d-model. and for a
3d-model it is much easier to scale up to size.

This makes sense.

but you are testing your middleware with a very unusual workload. what
is the point of that?

I guess at the time I wasn’t aware that it was that unusual of a workload… we deal with some pretty odd use-cases anyways, but you are right that it’s better to run the simulation correctly.

not just making things up and give you a hard time for
no good reason.

Never thought that :slight_smile:

Josh

There is no conceptual problem with having a huge

2d simulation. The only time you should get this error:

“Error: Domain too large for neighbor bins”

is if you blow atoms out of a non-periodic domain and

you are trying to bin a simulation box that has blown up.

Your script has non-periodic boundaries and you are
indenting a solid. I imagine the box has become
huge at the point you get that error.

Steve