Page 1 of 1

openmp issues

Posted: Thu Feb 09, 2012 2:25 am
by C.H.M. Broeders
After successful installation of serpent2.1.1 version without parallel options, I am trying to create parallel capabilities with openmp on MANDRIVA2011.0 64 bit computer.
After installing openmp and gomp packages compilation of serpent2 with default options for openmp in Makefile is successful. However, the command ./sss2 -version gives
"Parallel calculation mode not available".
As I am not an openmp expert I appreciate any comment on this on a first glance contrary information
Best greetings
C. Broeders

Re: openmp issues

Posted: Thu Feb 09, 2012 10:40 am
by Jaakko Leppänen
That message a leftover from Serpent 1, and concerns MPI parallelization. Try running the calculation with command line option "-omp 2". You should see something like:

Code: Select all

------------------------------------------------------------

Serpent 2.1.1 -- Neutron criticality source simulation

[...]

Options : (R) (O4) (DT) (OMP=2) 
------------------------------------------------------------
The "(OMP=2)" on the last line tells the number of OpenMP threads.

I'll fix the message in the next update.

Re: openmp issues

Posted: Thu Feb 09, 2012 1:10 pm
by C.H.M. Broeders
Thanks for the very effective communication.
I just performed some tests with VVER example on Debian Lenny 64 bit with following results for "calculation time":
1) No openmp: 2.89 minutes
2) Openmp no "-omp 2" input (1 processor)": 3.38 minutes (x1.17)
3) Openmp with "-omp 2" input (2 processors)": 1.67 minutes (x0.58)

Re: openmp issues

Posted: Thu Feb 09, 2012 4:31 pm
by Jaakko Leppänen
Looks pretty similar to my test calculations. Compiling with OpenMP adds some overhead that makes the calculation run slower with a single CPU, so if you are not planning to run parallel calculation, the source code is best compiled without OpenMP.

Re: openmp issues

Posted: Fri Feb 10, 2012 12:28 am
by C.H.M. Broeders
Most LINUX computer now have hardware with at least 2 CPUs. This means that the openmp option may save computation time by about 40%. Is there any argument not to apply openmp?
CB

Re: openmp issues

Posted: Fri Feb 10, 2012 1:05 am
by Jaakko Leppänen
Not really, and in my opinion it would help testing the calculation routines if OpenMP parallelization is used by default.

I will probably start looking at the root cause for the overhead at some point to see if there is some optimization to be done, but at the moment this is not a high priority. One thing that might improve the performance is setting the reproducibility option to 0:

Code: Select all

set repro 0
This will skip the sorting of the source points between cycles, which adds to CPU time consumed outside the parallelized loop.

Re: openmp issues

Posted: Fri Feb 10, 2012 1:30 am
by C.H.M. Broeders
If applied well (?) using "set repro 0" in my case improves calculation time from 1.41 to 1.37 minutes (on MANDRIVA2011.0 64 bit at home)
Further in my opinion 15-17% overhead for parallelization with linear process number speedup is a good implementation.
CB

Re: openmp issues

Posted: Fri Feb 10, 2012 11:32 pm
by Jaakko Leppänen
The impact of "set repro 0" should become more apparent when the population size is large (> 100,000 or so).