'bug' when using set density and diameter commands with spheres

Dear all,

I think I have found a bug in the code, which was introduced by the 13Apr11 patch.

Basically at the moment if a user first sets density and then diameter for spheres he will get a wrong result, whereas if they first set diameter and density they will not see any problem

The following lines reproduce the problem:

Basically at the moment if a user first sets density and then diameter for spheres he will get a wrong result, whereas if they first set diameter and > density they will not see any problem

The doc page for the set command states this explicitly:
Keyword diameter sets the size of the selected atoms. The particles
must be finite-size spheres as defined by the atom_style sphere
command. The diameter of a particle can be set to 0.0, which means
they will be treated as point particles. Note that this command does
not adjust the particle mass, even if it was defined with a density,
e.g. via the read_data command.

The issue is that the user can set the diameter to 0.0, to make what was
previously a finite-size sphere into a point particle (or vice versa).
And the code does not store the density of the particle, only the mass.
So any density value from the data file or a previous density command no
longer exists. So if you change the diameter, what should LAMMPS use
for the density of the particle if it wanted to reset the mass?
LAMMPS avoids these issues,
by not changing the mass - relying on the user to set it explicity
to what is wanted (e.g. via set mass or set density) if you change the
size of the particle.

I agree that this may not be transparent, but it is simple. I'm open
to alternate suggestions, but they
need to cover all the possible cases.

On another note we sometimes run 2D simulations with atom-type sphere, and LAMMPS sets the masses using a 3D formula (as stated in the manual).
But our atoms are really discs.
Would it be worth doing something like this in the code wherever necessary?

It would be possible to have a flag on atom_style sphere to use
discs instead of spheres. Or to have an atom_style disc I suppose.
It would introduce small changes in a handful of places in the code to
check on that flag. Again LAMMPS is explicit about the fact
it is using 3d spheroids (or ellipsoids) even for 2d simulations
(which is what many
people want), so 2d discs would be a distinctly different model.


Hi Steve,

Yes I understand, it is more of a logics issue than anything else, so it is not a bug at all. I just noticed that the manual has changed too since last April, so all should be fine.

As for the second part of my question sometimes we need to use discs with 2D simulations. The only difference at the moment is that mass and moment of inertia should be defined using a different formula. But some future granular pairs might be affected by the choice of sphere vs disc, as the area of contact between 2 spheres is a circle whereas the 'area' of contact between 2 discs is a line (this last fact is probably not so relevant at the moment).

So if I understand your suggestion well we would be adding an optional flag to the atom_style sphere command, which would give an error if the dimension is not 2. Then we would have an if-statement that would check which formula should be used every time masses and moments of inertia are set. At the moment we have the if (domain->dimension == 2) check in our local version of the code, but it would be interesting to know which option you think would work best with the rest of LAMMPS in case we find time to implement it.

Thanks and best wishes,


I think you have to allow users running in 2d to either do spheroids or discs.

Your point about the granular model is a good one. The Hertzian potential does
model repulsion based on the volume of overlap of 2 spheres. So I assume it
is incorrect for the overlap of 2 discs. That could well be true for
the tangential
term as well. I think all the granular potentials are parameterized
for 3d spheres.