## parallazation problem

General OpenMP discussion

### parallazation problem

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)
!\$      write(*,*) "Master Thread =", TID
!!     Only master thread does this
!\$       IF (TID .EQ. 0) THEN
!\$       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

### Re: parallazation problem

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

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

### Re: parallazation problem

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

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

### Re: parallazation problem

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