OpenMP and /QopenMP switch

Guillaume_d_ · ‎07-22-2015

Hello,

I encountered an issue due to openMP. The results from the sequential code is OK while the parallel one is wrong and random (suggesting a race condition). The structure looks like this :

!$OMP DO PRIVATE{i,j,var3}
do i = 1, n
[blabla...]

   do j=1,jj
      a = interpol( var1(i), j,  var3)
   end do

[blabla...]
end do
!$OMP END DO

where interpol is a library function with no common, share variable nor "save" attribute at all. Adding !$OMP CRITICAL around the inner do loop solves the issue but a significant part of the parallelization gain is lost.

Eventually I solved the issue by adding the /Qopenmp switch to the library compilation, even though there no OMP directive at all in the code. So problem solve but I missing the why and thus doubt about the robustness of the fix.

Can somebody explain me the effect of the /Qopenmp switch when there is no OMP directive ?

Thanks,

Guillaume

TimP · ‎07-22-2015

This has been explained many times on the Fortran forums. Ifort default is like SAVE status for local arrays. To change this without depending on Qauto or Qopenmp you would declare RECURSIVE procedures.

jimdempseyatthecove · ‎07-22-2015

In addition to your library routine not being compiled with /Qopenmp (or attributed routines with recursive), you inner loop is writing to shared variable a. I am aware the above is sketch code, this said, if your sketch contains such a mistake, your actual code may include the mistake as well.

Jim Dempsey

Guillaume_d_ · ‎07-22-2015

Thanks for the explanation, it is clear now. I will keep the /Qopenmp to compile the library.

About writting to a shared variable, it is a error in the above sketch (and not in the actual code.)

Regards,

Guillaume