Hello all,
I’ve been trying to compare the performance of OMP-enabled LAMMPS vs. pure OpenMPI, but have not succeeded in getting it to run properly. When compiling, I enabled USER-OMP, MANYBODY, and OPT only. When compiling using Intel compilers I added -openmp to both the CCflags and the Linkflags. We are using dual hexcore X5650 processors on our cluster. To test the executable, I’ve tried running it in a variety of ways. Here’s an example input file, in.1:
Hello all,
hello niraj,
I've been trying to compare the performance of OMP-enabled LAMMPS
vs. pure OpenMPI, but have not succeeded in getting it to run
if you want to compare performance, you should probably use the
second generation of the OpenMP support code, which is still sitting
in steve's inbox and waiting for when he has time to merge it
into the distribution. for the time being, you can download
my development version from github at:
http://github.com/akohlmey/lammps-omp
properly. When compiling, I enabled USER-OMP, MANYBODY, and OPT only.
When compiling using Intel compilers I added -openmp to both the
CCflags and the Linkflags. We are using dual hexcore X5650 processors
on our cluster. To test the executable, I've tried running it in a
variety of ways. Here's an example input file, in.1:----
package omp 6
units metal
boundary s p p
atom_style atomic
pair_style eam/alloy/omp
read_data CuNb_12.dat
pair_coeff * * cunbzbl.setfl Cu Nb
mass 1 63.5460
mass 2 92.9064
thermo_style custom spcpu step temp pxx pyy pzz
velocity all create 400.0 4928459 mom yes rot yes dist
uniform
thermo 100
fix 1 all nvt temp 300 300 1
run 5000
unfix 1
----When I run this directly:
~/lmp_new < in.1
I get "Invalid pair style" error.
that would mean, that you have not installed/compiled
your executable correctly. if the USER-OMP package is
installed correctly, you should not get an invalid pair
style error. the code in USER-OMP is written to run
correctly, regardless of whether OpenMP is enabled
or not. since it includes optimizations similar to
what is done in the OPT package (but only what is "safe")
it should run a little bit faster even without OpenMP.
If I run it with eam/alloy instead, and launch it with
~/lmp_new -sf omp -in in.1
It begins by saying
using 1 OpenMP thread(s) per MPI task
reset 6 OpenMP thread(s) per MPI taskSo I assume it compiled correctly, but it only shows a 1x1x1 processor
no, that only means that the main part of the code
is compiled with OpenMP support. if you don't have
the USER-OMP package included, LAMMPS will fall back
to use eam/alloy. the 1x1x1 processor grid refers
only to MPI tasks, so that is correct.
grid, and there is no speed up in the performance. Am I missing
something? I don't think the eam/alloy/omp was enabled correctly.
exactly. but this is likely due to a mistake on your
side, e.g. you could have installed USER-OMP before
you installed MANYBODY. packages like USER-OMP, OPT
and GPU only install those package that are compatible
what was installed before, so you have to install
them last. in the case of the latest development
version of USER-OMP, using "make package-update"
should now work, too. but this doesn't always work
for the other packages.
in any case, you should also note, that EAM is
one of the pair styles that are particularly
challenging to multi-thread with the way how
USER-OMP is programmed, since there are
multiple MPI communication steps inside the
pair style that require additional synchronizations
and thus have more overhead when using OpenMP.
it will be most beneficial, if you run system
that have load balancing issues in MPI, e.g.
with inhomogeneous particle distribution.
the latest development code has a modified
run summary output, that will print some information
about this, so it will be easier to decide
whether to use more MPI tasks or more OpenMP
threads when running a specific system.
also, you should keep in mind that the type
of processors you use has a high memory
bandwdith, which usually favors MPI parallelization
over OpenMP.
hope that helps,
axel.