topic If I remember correctly, and in Intel® Fortran Compiler

Unexpected results with OpenMP

Frederic_A_ — Fri, 12 Jun 2015 08:20:33 GMT

Now the sequential version of the code works (https://software.intel.com/en-us/forums/topic/559357), I tried to parallelize the loop at line 68 of myprog.f (see attached) using OpenMP.

As before, I use 'ifort -c mymod.f90' to compile the module.

Then I build the program successfully with:

c:\>ifort -openmp myprog.f mymod.obj
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.3.202 Build 20140422
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

-out:myprog.exe
-subsystem:console
-defaultlib:libiomp5md.lib
-nodefaultlib:vcomp.lib
-nodefaultlib:vcompd.lib
myprog.obj
mymod.obj

The programs runs without any error and generates correct results when setting the number of threads to 1 (num_threads(1) at line 63 of myprog) but incorrect results are obtained for some loop iterations when specifying more than one thread, as illustrated on the graph Plot.jpg.

The program performs integration of a function for several values of a variable, and each iteration of the loop I intend to parallelize corresponds to the computation of the integral for one of these values. These integral computations are completely independent, they just start using common input data and the only thing that basically changes from one iteration to the other is the loop index that define variable omega (line 69) and the other variables depending on it. After execution, it therefore provide an integral value for each value of variable omega and this is presented on the plot (Y axis -> value of the integral, X axis -> variable omega).

The blue curve are the correct results, obtained with the sequential version of the code as with num_threads(1). The red line are results obtained with num_threads(2), and shows some peaks with erroneous values. The peaks are not systematically reproducible (i.e., may change from one run of the program to the other).

Before I enter more deeply in the debugging process, do you see any obvious problem/mistake in the code that may explain such results? I defined all variables as private, except the input variables and the output one. I also defined all procedures of the module as recursive as it if often recommended on forums about such topics. From my first tests, I suspect the integration variable (line 772 of mymod) to be at the source of the problem, but without understanding why…

If I remember correctly, and

Arjen_Markus — Fri, 12 Jun 2015 08:35:12 GMT

If I remember correctly, and the OpenMP specification does indicate this, then variables that have no explicit data-sharing attribute have the attribute "shared". This could be causing the haphazard spikes you see. (page 157 of the OpenMP 4.0 specifications: In a parallel construct, if no default clause is present, these variables are shared).

At the very least I would specify an explicit private attribute for all variables, like omega and zeta, that appear in the do-loop and that are not already shared.

Regards,

Arjen

Hi Arjen

Frederic_A_ — Fri, 12 Jun 2015 08:59:22 GMT

Hi Arjen

Thank you for your suggestion.

As fas as I understand, I already defined all data as private by default (default(private)) in the !$omp parallel directive and shared explicitely only the common input variables and the output vector in which each thread will save its result at the corresponding index (see lines 63-65 of myprog). Is there a more proper way to do it?

Oops, I completely overlooked

Arjen_Markus — Fri, 12 Jun 2015 09:11:46 GMT

Oops, I completely overlooked that bit. Hm, then my suggestion is completely superfluous.

But I do see this typo:

!$opm do

Could that be the thing that is causing this?

Regards,

Arjen