OMP problem with xlf on BGq.

Dear users,

I am having problems to run lammps with OpenMP in BGq machines, and it is an important thing to use on such machines, as there is almost a fourfold increase in performance when using threads in lammps (-sf omp).

The code compiles, but on all omp subroutines it gives messages of this kind:
“…/angle_charmm_omp.cpp”, line 63.20: 1540-1664 (W) The variable “fix” has undefined data scope.

When I try to run lammps with -sf omp I always get lost Bonds/Atoms after a small simulations time. But, without the -sf omp the simulations goes smoothly, but of course a lot slower.

I tried disabling some optimization options of the xlf compiler, but it doesn’t seem to help.

I am stuck now, and in the xlf documentation about the compiler message is only says I should define a data scope for the variable.

So, any help to understand this problem will be welcome.

Kind regards,

Makefile.bgq.volcano (1.21 KB)

Makefile.bgq.volcano.details (3.26 KB)

Dear users,

I am having problems to run lammps with OpenMP in BGq machines, and it is an
important thing to use on such machines, as there is almost a fourfold
increase in performance when using threads in lammps (-sf omp).
The code compiles, but on all omp subroutines it gives messages of this
kind:
"../angle_charmm_omp.cpp", line 63.20: 1540-1664 (W) The variable "fix" has
undefined data scope.
When I try to run lammps with -sf omp I always get lost Bonds/Atoms after a
small simulations time. But, without the -sf omp the simulations goes
smoothly, but of course a lot slower.

I tried disabling some optimization options of the xlf compiler, but it
doesn't seem to help.

this has nothing to do with optimizations, but seems to be a bug in
the xlC (not xlf!) compiler version on your machine. i know for a fact
that this code has worked on multiple blue gene machines.

I am stuck now, and in the xlf documentation about the compiler message is
only says I should define a data scope for the variable.

the scope of "fix" is well defined. it is a class member of
AngleCharmOMP and as such automatically "shared". placing it into the
"shared()" directive of the omp pragma would be an error (and many
compilers will refuse to compile such code).

what you should try is to see, if there are different versions of the
compiler installed and whether the code gets miscompiled with all of
them.

Thank you for your quick response Axel.

The machine has the 12.0 version of xlC (sorry for the mistake with xlf, so used to fortran codes).

I will ask for the admin if they plan to upgrade to version 12.1, that is the latest and has support for OpenMP 3.1, maybe that is really the problem.

Thank you again Axel.