Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

Unexpected results with OpenMP

Frederic_A_
Beginner
1,092 Views

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.

Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft 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…

0 Kudos
3 Replies
Arjen_Markus
Honored Contributor II
1,092 Views

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

0 Kudos
Frederic_A_
Beginner
1,092 Views

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?

 

0 Kudos
Arjen_Markus
Honored Contributor II
1,092 Views

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

 

0 Kudos
Reply