large other time

Dear all,

Sorry for disturbing you, in my simulation whit lammps (28 Jul 2015), I got following out put for runnin times:

Loop time of 31768.4 on 4 procs (4 MPI x 1 OpenMP) for 16000000 steps with 31298 atoms

Pair time () = 9553.57 (30.0726) Neigh time () = 314.641 (0.990421)
Comm time () = 920.07 (2.89618) Outpt time () = 22.9413 (0.0722142)
Other time (%) = 20957.1 (65.9686)

Nlocal: 7824.5 ave 7896 max 7715 min
Histogram: 1 0 0 0 0 1 0 0 0 2
Nghost: 334.5 ave 339 max 327 min
Histogram: 1 0 0 0 0 0 1 0 1 1
Neighs: 15002.8 ave 15255 max 14686 min
Histogram: 1 0 0 0 1 0 0 1 0 1

Total # of neighbors = 60011
Ave neighs/atom = 1.91741
Neighbor list builds = 108103
Dangerous builds = 4

As you see, pair, neigh, comm and output times are reasonable, but other time is very large,
I read the manual but I can’t find details of other time, is there any Idea about other time and an strategy to reduce this large time?

and my code is:

units cgs
dimension 2
atom_style sphere
boundary p f p
processors 4 1 1
newton off




#************* main run
pair_style gran/hertz/history {Kn} NULL {gam_n} {gam_n} {fric} 1
pair_coeff * *
fix wal all wall/gran {Kn} NULL {gam_n} {gam_n} 0.9 1 yplane 0.0 {y_high}

fix 2D all enforce2d
fix ensmble all nve/sphere
fix gravit all gravity {g_prime} vector 0 -1 0 fix visc all viscous {gamma}

#compute 1 all erotate/sphere
neighbor 0.0025 bin
thermo 20000
thermo_style custom step cpu
comm_modify vel yes
timestep 0.0002
run_style verlet
#**************************************** run and dump **************************************************#
dump 2 all xyz 5000 vmd/*.xyz
run 16000000

Thanks in Advance,
Reza

Time spent in fix styles are categorized into Other time: so it could be any of your fixes. You can take one fix out at a time and see if you get a performance gain - then you will know which fix is reducing the performance.

Ray

Time spent in fix styles are categorized into Other time: so it could be any
of your fixes. You can take one fix out at a time and see if you get a
performance gain - then you will know which fix is reducing the performance.

also, with newer versions of LAMMPS, the "Other" time is split into a
"real" other and "Modify", which consists of fixes and computes.

with granular simulations, having a significant amount of time spent
in "Modify" is not unusual. the pair computation is much faster than
for other potentials, because the cutoff is very short. if the new
version of LAMMPS *still* has so much time in "Other" we need to look
at the simulation more closely.

axel.