On Sat, 2011-10-29 at 16:38 +0000, Gupta, Niraj wrote:
> 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
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:
> 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
> 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 task
> So 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
hope that helps,
> Thanks in advance.
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World™ now supports Android™ Apps
> for the BlackBerry® PlayBook™. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
> lammps-users mailing list