Question

I have this piece of Open MP code here which performs an integeration of the function 4.0/(1+x^2) on the interval [0,1]. The analytical answer to this is pi = 3.14159...

The method of integrating the function is just by a plain approximating Riemann sum. Now the code
gives me the correct answer when I use 1 OpenMP thread, upto 11 OpenMP threads.

However it starts giving increasingly wrong answers once I start using 12 OpenMP threads or more.
Why could this be happening? First here is the C++ code. I am using gcc in an Ubuntu 10.10 environment. The code is compiled with g++ -fopenmp integration_OpenMP.cpp

// f(x) = 4/(1+x^2) 
// Domain of integration: [0,1] 
// Integral over the domain = pi =(approx) 3.14159 

#include <iostream>
#include <omp.h>
#include <vector>
#include <algorithm>
#include <functional>
#include <numeric>


int main (void)
{
  //Information common to serial and parallel computation.
  int    num_steps = 2e8;
  double dx        = 1.0/num_steps;


  //Serial Computation: Method pf integration is just a plain Riemann sum
   double start = omp_get_wtime();

   double serial_sum = 0;
   double x          = 0;
   for (int i=0;i< num_steps; ++i)
      {
         serial_sum += 4.0*dx/(1.0+x*x);
              x += dx;
     }

    double end = omp_get_wtime();
    std::cout << "Time taken for the serial computation: "      << end-start         << " seconds";
    std::cout << "\t\tPi serial: "                              << serial_sum        <<   std::endl;





   //OpenMP computation. Method of integration, just a plain Riemann sum
    std::cout << "How many OpenMP threads do you need for parallel computation? ";
    int t;//number of openmp threads
    std::cin >> t; 

    start  = omp_get_wtime(); 
    double  parallel_sum = 0; //will be modified atomically
    #pragma omp parallel num_threads(t)
    {
      int threadIdx = omp_get_thread_num();
      int begin = threadIdx * num_steps/t; //integer index of left end point of subinterval
      int end   = begin + num_steps/t;   // integer index of right-endpoint of sub-interval
      double dx_local = dx;
      double temp = 0;
      double x    = begin*dx; 

      for (int i = begin; i < end; ++i)
    {     
         temp += 4.0*dx_local/(1.0+x*x);
         x    += dx_local;
    }
     #pragma omp atomic
      parallel_sum += temp;
     }
    end   = omp_get_wtime();
    std::cout << "Time taken for the parallel computation: "    << end-start << " seconds";
    std::cout << "\tPi parallel: "                                << parallel_sum        <<   std::endl;

    return 0;
}

Here is the output for different number of threads starting with 11 threads.

OpenMP: ./a.out
Time taken for the serial computation: 1.27744 seconds      Pi serial: 3.14159
How many OpenMP threads do you need for parallel computation? 11
Time taken for the parallel computation: 0.366467 seconds   Pi parallel: 3.14159
OpenMP: 
OpenMP: 
OpenMP: 
OpenMP: 
OpenMP: 
OpenMP: ./a.out
Time taken for the serial computation: 1.28167 seconds      Pi serial: 3.14159
How many OpenMP threads do you need for parallel computation? 12
Time taken for the parallel computation: 0.351284 seconds   Pi parallel: 3.16496
OpenMP: 
OpenMP: 
OpenMP: 
OpenMP: 
OpenMP: 
OpenMP: ./a.out
Time taken for the serial computation: 1.28178 seconds      Pi serial: 3.14159
How many OpenMP threads do you need for parallel computation? 13
Time taken for the parallel computation: 0.434283 seconds   Pi parallel: 3.21112


OpenMP: ./a.out
Time taken for the serial computation: 1.2765 seconds       Pi serial: 3.14159
How many OpenMP threads do you need for parallel computation? 14
Time taken for the parallel computation: 0.375078 seconds   Pi parallel: 3.27163
OpenMP: 

Answer 1

Why not just use a parallel for with static partitioning instead?

#pragma omp parallel shared(dx) num_threads(t)
{
   double x = omp_get_thread_num() * 1.0 / t;

   #pragma omp for reduction(+ : parallel_Sum) 
   for (int i = 0; i < num_steps; ++i)
   {     
       parallel_Sum += 4.0*dx/(1.0+x*x);
       x += dx;
   }
}

Then you won’t need to manage all the partitioning and atomic collection of results by yourself.

In order to correctly initialize x, we notice that x = (begin * dx) = (threadIdx * num_steps/t) * (1.0 / num_steps) = (threadIdx * 1.0) / t.

Edit: Just tested this final version on my machine and it seems to work correctly.