parallazation problem

General OpenMP discussion

parallazation problem

Postby rudra » Wed Jun 11, 2008 8:29 pm

In a part of my code, i am trying to paralize the do loop labeled by
mcstp:
Code: Select all

       open(16,file=filrdf,status='replace')
        write(*,'(1x,"Monte Carlo calculation")')
!$OMP PARALLEL SHARED(X,Y,Z,ISTP) PRIVATE(TID)
!$      TID=OMP_GET_THREAD_NUM()
!$      write(*,*) "Master Thread =", TID
!!     Only master thread does this
!$       IF (TID .EQ. 0) THEN
!$         NTHREADS = OMP_GET_NUM_THREADS()
!$         write(*,*)  'Number of threads = ', NTHREADS
!$       END IF
!$OMP DO

mcstp:  do istp=1,rmcs

           iatm=int(ntot*rvec(istp))+1
           old_x=x(iatm);old_y=y(iatm);old_z=z(iatm)

           x(iatm)=x(iatm)+dr*(rvec(iatm)-0.5)
           y(iatm)=y(iatm)+dr*(rvec(iatm)-0.5)
           z(iatm)=z(iatm)+dr*(rvec(iatm)-0.5)
          call PBC(x,y,z,boxl)
          call crdf(filrdf,x,y,z,boxl,ntot,nap,rrl,gr_new,rmin,exst)
!       write(*,*) gr_new
            if (.not.exst) then
            write(*,*) "Problem in openning file ",filrdf,"in step",istp
            stop
            endif

        mcst=rmcs/10
        if (mod(istp,mcst)==0) write(*,'(a2,$)') ". "
!---------------------------------------------------------------

        call metropolis(rdf_ex,gr,gr_new,ntot,chng,rho,boxl,sigma,istp)
        if (chng==1)then
         x(iatm)=old_x
         y(iatm)=old_y
         z(iatm)=old_z
        end if

        end do mcstp
!$OMP END DO
!$OMP END PARALLEL
        close(16)


where i am expecting the do loop will be shared by all threads equally (say, if rmcs=1000,istp1=100 will work on first thread,101 to 200 on 2nd thread and so on) but its not ...whats wrong in the code and how to make it correct? all the other subroutine is serial and i am using gfortran -fopenmp
rudra
 
Posts: 21
Joined: Tue Jun 03, 2008 5:28 am
Location: kolkata,india

Re: parallazation problem

Postby ejd » Wed Jun 11, 2008 8:59 pm

What does the output from this section look like? How do you know you are not getting the work done as expected?

Looking at the code some more, I think part of your problem is that "iatm", "old_x", "old_y", and "old_z" most likely all need to be private.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: parallazation problem

Postby rudra » Wed Jun 11, 2008 9:39 pm

thnx for your reply.
i have not given the output because its calculated in subroutine crdf which is serial routine. the problem is, as far as i can think is , i am not giving the data to the subroutine in right order.
the code is wrong because it doesn't math the result of serial calculation
rudra
 
Posts: 21
Joined: Tue Jun 03, 2008 5:28 am
Location: kolkata,india

Re: parallazation problem

Postby ejd » Wed Jun 11, 2008 10:01 pm

The problem is, that from what I can see of your code, you need to privatize more of the variables. Currently you have race conditions on several of the variables. I listed a few in the last response. There are others like "chng" that also most likely need to be private. Your use of "exst" to write to a file could cause a race on the file as well. I don't know since it is set in a subroutine and I don't know if you are opening multiple files or not. The setting of "mcst" is a race - but it seems benign and most likely can be ignored. Personally I like to eliminate all races in my code, so when I use a race detection tool, only races that I need to handle will appear.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: parallazation problem

Postby rudra » Wed Jun 11, 2008 10:08 pm

race detection tool??? whats that?i am a beginner and thats my first real program except those hello world and matrix multiplication!!! can you plz be a little more explicit?
rudra
 
Posts: 21
Joined: Tue Jun 03, 2008 5:28 am
Location: kolkata,india

Re: parallazation problem

Postby ejd » Mon Jun 16, 2008 6:28 am

Sorry for the delay. My "day job" is keeping me quite busy at the moment. In any case, to answer your question, take the following simple example:

Code: Select all
int main void
{
  int a = 0;
  #pragma omp parallel
  {
    a = a + 1;
  }
  return 0;
}

This has a race condition. Generally a race, (not the formal definition) is when you have an execution of one or more lines of code where the value of a variable is being written and read/written at the same time. In these cases, the outcome is uncertain and you want to remove this sort of problem from your code.

In my example above, the value of "a" is being read on the right hand side and written on the left hand side. When two or more threads execute this at the same time, the result will be indeterminate. There are many ways to fix this example (a reduction clause, use of atomic or critical, etc). However, the problem is to find these conditions, especially when the code that is causing the race is quite disjunct (or scattered among many different modules).

In my simple example, a compiler or static race tool, should give you some idea of the problem. For example, the Sun compiler using the -xvpara flag, gives the following message at compile time:

Code: Select all
"a.c", line 4: Warning: inappropriate scoping
        variable 'a' may be scoped inappropriately as 'shared'
        . write at line 6 and write at line 6 may cause data race

However, most compilers do not do static race analysis across multiple modules or for the whole program. This would increase compile time considerably and still not catch all the race conditions. For example:

Code: Select all
int a;

void func(void)
  a = a + 1;
}

int main(void) {
  #pragma omp parallel
  {
    func();
  }
  return 0;
}

The above code is still quite simple. However, what if the function were in a separate compile from the main procedure. Then there is no way the compiler would know that function "func" is being called from within a parallel region. Without this information, the compiler couldn't do a valid static analysis. Another problem, is the use of pointers. The compiler has no way to determine which variables are being modified at compile time.

This means that there has to be a tool to check at run time whether races are occurring. The tool, essentially instruments the code to look at loads and stores to see which storage locations are being modified and read from and then has to relate this back to line numbers (and variable names) in the source code. This of course increases the run time quite a bit, but hopefully you only have to do it a few times while debugging your program. Hope that helps explain the problem.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am


Return to Using OpenMP

Who is online

Users browsing this forum: Yahoo [Bot] and 5 guests