ifort openmp vs. gfotrtran openmp

ifort openmp vs. gfotrtran openmp

Hey everyone,

So I have a loop that works perfectly with openmp using gfortran, I.E. it produces the right results. However I recently had to switch to the IFORT compiler, and found that the code no longer produces the right result using IFORT. If you are familiar with molecular simulations, this is a linked cell energy calculation. I'm sorry if the code isn't clear enough, but given that it works with gfortran, can anyone see any glaring reason why the IFORT compiler would not like this? If I run this code using IFORT, the final energy reported is 0.0, however if i use gfortran the answer is 105555.11. I don't know where to really start here, since the code works with gfortran.

             energy= 0.0d0

 !$omp parallel do schedule(dynamic) reduction(+:energy) default(private) shared(r,tr,cv,param,envar,alpha,GaussChar,pf)

    !dir$ vector aligned
    !--- loop over all cells

    !--- listvar%ncellT is the total number of cells in the simulation

    do i = 0, listvar%ncellT-1

        !--- pointers to the region of position array (r) where the atoms of cell i are located

       c1s   = tr(i)%start
       c1e   = tr(i)%end

       energy = energy +  cell_self_energy_local(c1s,c1e)
       do k=1,26
          !---determine this cell
          cell_neigh = cv(k,i)%cnum
             !---minimum image
             minx =cv(k,i)%min_x
             miny =cv(k,i)%min_y
             minz =cv(k,i)%min_z
             c2s = tr(cell_neigh)%start
             c2e = tr(cell_neigh)%end
             !--- loop over particles in each cell         
             do j = c1s,c1e

                !--- r is the global position array containing a data type which hold the x,y,z coordinates and type of the atom
                x1 = r(j)%x
                y1 = r(j)%y
                z1 = r(j)%z
                type1 = r(j)%type


                do l= c2s,c2e
                   x2 = r(l)%x
                   y2 = r(l)%y
                   z2 = r(l)%z
                   type2 = r(l)%type
                   !--- obtain displacements
                   !--- apply minimum image here
                   dx = x2-x1-minx
                   dy = y2-y1-miny
                   dz = z2-z1-minz
                   dr2 = dx*dx+dy*dy+dz*dz


                       !---- envar is an array containing atom interaction energy parameters (sig and epsilon)

                      eps    = envar(type1,type2)%eps
                      sig    = envar(type1,type2)%sig
                      charge = envar(type1,type2)%q
                      sig2   = sig*sig
                      dr    = sqrt(dr2)
                      dri   = 1.0d0/dr
                      dr2i  = sig2/dr2
                      dr6i  = dr2i*dr2i*dr2i
                      dr12i = dr6i*dr6i


                      !--- lennard jones energy
                      energy = energy + 4.0d0*eps*(dr12i - dr6i)      


                      !--- electrostatic energy            
                      energy = energy + pf*charge*(erfc(alpha*dr)-GaussChar)

    !$omp end parallel do

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

This doesn't look topical here, unless you actually using that open source OpenMP library.  The primary data race debugging tool offered for OpenMP with ifort is the Inspector tool, for which there is a separate forum (and there are separate forums for ifort Windows and linux).

That data races don't materialize on one compiler could be an accident, possibly associated with differences in register optimizations.  You can link the gfortran against the libiomp5.so If you're interested to try that variation. 

I am using the open source openmp library.

Ok, so following your advice I learned how to use the intel debugger. This is the result I am getting

Thread 9 stopped at the following line:

x2 = r(l)%x 

​with signal SIGSEGV(seg fault)

Reason/origin: address not mapped to object (attempt to access invalid address).

Does anyone have any idea why this is happening?

This still doesn't seem in any way related to the open-source runtime. (Why are you even using it as against the one that came with the compiler? [not that there are any substantive differences, merely that it seems an unnecessarily complicated thing to be doing]).

This looks like a bug of some sort in your code that is being made visible by the Intel compiler. Without all the code it's pretty hard to debug that, and this isn't the right place to be doing it.

At a guess, 'l' is out of bounds...

I concur that the question does not look like related to open-source runtime.

Just want to mention that your code does not look compliant because it uses uninitialized variable as a loop bound:

!$omp parallel do schedule(dynamic) reduction(+:energy) default(private) shared(r,tr,cv,param,envar,alpha,GaussChar,pf)
     do i = 0, listvar%ncellT-1

Here you are using listvar%ncellT variable which is private and not initialized so can have any values in different threads.



Leave a Comment

Please sign in to add a comment. Not a member? Join today