[lammps-users] Error in create_atoms depending on number of processors used

LAMMPS LAMMPS Mailing List Mirror
1

Dear LAMMPS-creators,

I’m doing a simulation of crystalline zirconia, for which I have to define the unit cell myself. When I run my simulation on 16 processors the correct lattice structure is created, but when I use 32 processors some of the Zr atoms are missing. Even more strangely, when I changed the lattice parameter from the physically sensible value of 5.114 angstrom to 5 angstrom (for easier analysis of the dumps), the correct number of atoms was created. My input script is as follows (the number of unit cells in the x- and y-directions is reduced to 1 for ease of debugging).

boundary p p p
units metal
atom_style charge

lattice custom 5.114 a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0117325 &
origin 0.0 0.0 0.0 basis 0.0 0.0 0.0 basis 0.5 0.5 0.0 basis 0.5 0.0 0.5 basis 0.0 0.5 0.5&
basis 0.285 0.285 0.285 basis 0.715 0.215 0.215 basis 0.215 0.715 0.215 basis 0.785 0.785 0.285 basis 0.285 0.285 0.785 basis 0.715 0.215 0.715 basis 0.215 0.715 0.715 basis 0.785 0.785 0.785

region mybox block 0 1 0 1 0 96
create_box 2 mybox
create_atoms 2 box basis 1 1 basis 2 1 basis 3 1 basis 4 1&
basis 5 2 basis 6 2 basis 7 2 basis 8 2&
basis 9 2 basis 10 2 basis 11 2 basis 12 2

neigh_modify delay 0 every 1000 one 20000 page 200000 check yes

group Zr type 1
group O type 2
set group Zr charge 4
set group O charge -2
mass 1 91.224
mass 2 16.000

pair_style buck/coul/long 10
pair_modify shift yes
pair_coeff 2 2 9547.96 0.224 32.0 10
pair_coeff 1 2 1502.11 0.345 5.10 10
pair_coeff 1 1 0000.00 0.345 0.00 10

kspace_style pppm 1.0e-5

dump d all custom 1 atoms.dump id type x y z
dump_modify d format “%d %d %20.15g %20.15g %20.15g”
run 0
undump d

On 16 processors log.lammps produces

Created orthogonal box = (0 0 0) to (5.114 5.114 496.56)
1 by 1 by 16 processor grid
Created 1152 atoms
384 atoms in group Zr
768 atoms in group O

but on 32 processors it says

Created orthogonal box = (0 0 0) to (5.114 5.114 496.56)
1 by 1 by 32 processor grid
Created 1150 atoms
382 atoms in group Zr
768 atoms in group O

I’m using the version from 23 March 2010. The missing atoms have the following ID, type and coordinates:
1045 1 0 0 450.007500201666
1046 1 2.55700000000000 2.55700000000000 450.007500201666

Regards,
Philip

2

When I run these lines:

boundary p p p
units metal
atom_style charge
lattice custom 5.114 a1 1.0 0.0 0.0 a2 0.0 1.0 0.0 a3 0.0 0.0 1.0117325 &
        origin 0.0 0.0 0.0 basis 0.0 0.0 0.0 basis 0.5 0.5 0.0 &
        basis 0.5 0.0 0.5 basis 0.0 0.5 0.5 basis 0.285 0.285 0.285 &
        basis 0.715 0.215 0.215 basis 0.215 0.715 0.215 &
        basis 0.785 0.785 0.285 basis 0.285 0.285 0.785 &
        basis 0.715 0.215 0.715 basis 0.215 0.715 0.715 basis 0.785 0.785 0.785
region mybox block 0 1 0 1 0 96
create_box 2 mybox
create_atoms 2 box basis 1 1 basis 2 1 basis 3 1 basis 4 1 &
                        basis 5 2 basis 6 2 basis 7 2 basis 8 2 &
                        basis 9 2 basis 10 2 basis 11 2 basis 12 2

I get 1152 atoms created on 16 or 32 or any # of procs.

This is with a g++ or Intel compiled Linux version.
This is with the current (1Jul10) fully patched version of the code.

Steve

3

Hmm, I tested the commands again on another computer cluster and I also get 1152 atoms irrespective of the number of processors. On the cluster I mainly use, on the other hand, I get 1150 atoms with 32 processors. Does this imply that I need to re-compile, possibly changing some options?

Thanks,
Philip

4

I don't think compilation flags will change anything. I think you
need to instrument
the create_atoms routines to see why those 2 atoms are being dropped, possibly
some kind of round-off issue. They are undoubtably being generated but then
discarded for some reason. You'll have to do it since I can't
recreate the problem.

Steve

5

Steve,

I simplified my script before I sent it to you, and subsequently discovered that I eliminated the mistake in the process. Apologies. Could you try the lines below on your system? The difference is in the size of a3, which is now defined via the division of two variables rather than as an explicit number, which supports your suggestion of a round-off problem.

Philip

boundary p p p
units metal
atom_style charge
variable a equal 5.114
variable c equal 5.1725
variable c2a equal $c/a lattice custom 5\.114 a1 1\.0 0\.0 0\.0 a2 0\.0 1\.0 0\.0 a3 0\.0 0\.0 {c2a} &
        origin 0.0 0.0 0.0 basis 0.0 0.0 0.0 basis 0.5 0.5 0.0 &
        basis 0.5 0.0 0.5 basis 0.0 0.5 0.5 basis 0.285 0.285 0.285 &
        basis 0.715 0.215 0.215 basis 0.215 0.715 0.215 &
        basis 0.785 0.785 0.285 basis 0.285 0.285 0.785 &
        basis 0.715 0.215 0.715 basis 0.215 0.715 0.715 basis 0.785 0.785 0.785
region mybox block 0 1 0 1 0 96
create_box 2 mybox
create_atoms 2 box basis 1 1 basis 2 1 basis 3 1 basis 4 1 &
                 basis 5 2 basis 6 2 basis 7 2 basis 8 2 &
                 basis 9 2 basis 10 2 basis 11 2 basis 12 2

6

I'll take a look, but it might be a couple weeks. I'm about to be out of
town for a week.

Steve

7

It was a round-off issue - I posted a 17Jul patch for it today.

Thanks,
Steve