Problems of using different numbers of processors

Dear Lammps Users,

I am using Lammps to simulate the compression test on copper single crystal and polycrystal samples at 300K. In the beginning, I used 16 nodes to run the simulation. When I used a bigger sample for the same simulation, I had to use 64 nodes to run the same simulation. I plotted the stress-strain curve for both the results and surprisingly there was a big difference between them. As you can see from the attached graph, for 16 nodes, the yield strength of single crystal is smaller than that of polycrystal. But for 64 nodes, the yield strength of single crystal is much bigger than that of polycrystal. Now this makes the situation totally contradictory as the polycrystal’s result can either be smaller or bigger than the single crystal’s, and not be both.

I noticed in the Lammps website, there are some discussions about the problems of using different numbers of processors. I had used “velocity” command in my simulation so, I tried to change the “Loop” option from “all” to “geom” but it still gave the same problem with the curves. I also tried to use “read_data” instead of “create_atoms” to create my single crystal sample but in vain.

I would really appreciate if you could provide me with some suggestions to fix this problem.

Thanks a lot for your time.

Shuyin

comparison.pdf (124 KB)

Dear Lammps Users,

I am using Lammps to simulate the compression test on copper single crystal
and polycrystal samples at 300K. In the beginning, I used 16 nodes to run
the simulation. When I used a bigger sample for the same simulation, I had
to use 64 nodes to run the same simulation. I plotted the stress-strain
curve for both the results and surprisingly there was a big difference
between them. As you can see from the attached graph, for 16 nodes, the
yield strength of single crystal is smaller than that of polycrystal. But
for 64 nodes, the yield strength of single crystal is much bigger than that
of polycrystal. Now this makes the situation totally contradictory as the
polycrystal's result can either be smaller or bigger than the single
crystal's, and not be both.

please clarify, did you run the _same_ system with 16 and 64 nodes?
or did you run the smaller system only with 16 and the larger with 64 nodes?

only in the first case, you could claim that the number of processors
has an impact, and in that case, it would be required that you provide
proper input files for verification, since this should not be the case.

however, in the second case, it is more likely that you are seeing
a simple finite size effect, as it happens a lot in MD; the systems
are typically too small to be fully converged with respect to the
system size.

cheers,
     axel.

Hi Axel,

Thank you for your reply.

I ran the same system with 16 and 64 nodes. Below is my code. I tried to use “all” and “geom” of “Loop” option, and also tried to use “read_data” instead of “create_atoms” to create my single crystal sample but in vain. Could you help me verify it? Thank you very much.

Shuyin

Compression test on Cu single crystal

T=300K

units metal
boundary s s s
atom_style atomic

lattice fcc 3.632
region box block -3 3 -4 4 -20 10
create_box 1 box
create_atoms 1 box

pair_style eam/alloy
pair_coeff * * Cu_mishin1.eam.alloy Cu

neighbor 2.0 bin
neigh_modify delay 5

region uppermobile block INF INF INF INF 8.75 INF
region lowerfix block INF INF INF INF INF -18.75
group uppermobile region uppermobile
group lowerfix region lowerfix
group boundary union lowerfix uppermobile
group mobile subtract all boundary

equilibrate

compute centro all centro/atom fcc
compute mobile_temp mobile temp
compute mobile_stress mobile stress/atom
compute stress mobile reduce sum c_mobile_stress[3]

variable szz equal c_stress/vol

velocity all create 600 1235654 temp mobile_temp loop geom

fix 1 all nvt temp 300 300 0.1 drag 2.0
fix_modify 1 temp mobile_temp

thermo 500
thermo_style custom step temp lx ly lz press pxx pyy pzz
thermo_modify temp mobile_temp
thermo_modify lost warn norm yes

run 50000

write_restart restartSC.0

Compression

velocity uppermobile set 0 0 -0.02 units box
velocity lowerfix set 0.0 0.0 0.0 units box

fix 2 boundary setforce 0 0 0

reset_timestep 0
thermo 100
thermo_style custom step temp lx ly lz v_szz
thermo_modify temp mobile_temp

restart 10000 restartSC.*

run 800000

Did the two simulation agree initially in thermo output
for a few 100 steps, then slowly diverge? If so,
that is normal behavior due to round-off.

Steve