Problem with Thread Checker & OpenMP

[Peter_Simon]

Hi, I hope this is the correct forum for this question. I am an experienced Fortran programmer but a newbie wrt threads and OpenMP. I'm attempting to parallelize the following loop using OpenMP and the Intel v. 8 Fortran compiler for windows (within the Microsoft dotnet 2003 IDE):

HF = 0.
HF1 = 0.; HF2 = 0.; HF3 = 0. !pss 7/5/2004 for OMP
!$OMP PARALLEL DO PRIVATE(J_INT1,RK,RK2,RKL,RK3R,CFAC,CJ1) &
!$OMP & REDUCTION(+:HF1) REDUCTION(+:HF2) REDUCTION(+:HF3)
First_refl_loop : &
DO J_INT1 = 1, N_INT1

! Vector RK from first to second reflector times wavenumber
RK(1) = (PUF(1) - P_R1%X(J_INT1))*AK
RK(2) = (PUF(2) - P_R1%Y(J_INT1))*AK
RK(3) = (PUF(3) - P_R1%ACTZ(J_INT1))*AK

! RK2 : RK**2
RK2 = RK(1)**2 + RK(2)**2 + RK(3)**2

! RKL : Length of RK
RKL = SQRT(RK2)

! RK3R : 1/RKL**3
RK3R = 1./(RKL*RK2)

! CFAC : Complex factor
CFAC = FAC*RK3R*(1.+AJ*RKL)*(COS(RKL)-AJ*SIN(RKL))

! CJ1 : Current element on first reflector
CJ1 = P_C1%CUR(:,J_INT1+I_OFF1)

! HF : H-field incident on second reflector
!!$ HF(1) = (CJ1(2)*RK(3)-CJ1(3)*RK(2))*CFAC + HF(1)
!!$ HF(2) = (CJ1(3)*RK(1)-CJ1(1)*RK(3))*CFAC + HF(2)
!!$ HF(3) = (CJ1(1)*RK(2)-CJ1(2)*RK(1))*CFAC + HF(3)
HF1 = (CJ1(2)*RK(3)-CJ1(3)*RK(2))*CFAC + HF1
HF2 = (CJ1(3)*RK(1)-CJ1(1)*RK(3))*CFAC + HF2
HF3 = (CJ1(1)*RK(2)-CJ1(2)*RK(1))*CFAC + HF3
END DO First_refl_loop
!$OMP END PARALLEL DO
HF(1) = HF1; HF(2) = HF2; HF(3) = HF3; ! pss 7/5/2004 for OMP

I compiled the debug versionwith /Qopenmp using the IDE settings (also including /FIXED:NO on the linker command line and set up a Thread Checker Activity. After running the acitivity, I obtain several diagnostics, including a severity "red" one that reads: "Using of a syncrhonization object at "optim3.f90" : 3417 conflicts with its closing at "a_map.c" : 53"

Line 3417 is the line beginning with "HF1 = 0."

There is also a "yellow": warning that a thread at "optim4.f90" : 3417 has been waiting more than 3 seconds trying to acquire a resource.

I don't understand the first of these messages. "a_map.c" appears to be some sort of system routine involving threads that is only available in machine code. I don't know how to proceed to solve this problem, if there even is a problem. I also don't understand the reason for the second (yellow) warning. There shouldn't be any resource conflict, if I've coded the OpenMP directives correctly.

A printout of the diagnostic messages from Thread Checker and the Fortran source code file are available on my web site at www.vcnet.com/~simonp/pos4, along with the project configuration files from the IDE.

Any assistance would be greatly appreciated.

Thanks,

Peter SImon

[Henry_G_Intel]

Hi Peter,

The /Qtcheck option is required to analyze OpenMP code. Did you use this option? If not, please try again with this option and let us know what happens.

I don't see any errors in your example program. A couple of comments about your OpenMP:

1. You can declare multiple variables in the same reduction clause.
2. It appears that you modified your code to replace HF(3) with three scalars. OpenMP 2.0 supports array reductions so you could have declared HF in the reduction clause, provided it's not a deferred shape or assumed size array.

Best regards,

Henry

PS This forum is fine for questions about the Intel Threading Tools. If we can't answerthe question, we'll provide apointerto Intel Premier Support.

[TimP]

Message Edited by tim18 on 08-25-2004 03:59 PM

[Peter_Simon]

Hi, Henry.

Thanks for responding. I had used the /Qtcheck option on the compiler command line but not on the linker command line. When I added it to the linker command line, it made no difference.

Re your comments:

1. Thanks, I will use the abbreviated form in the future.

2. I need to maintain compatibility with OpenMP 1.0 because the code will also be used on some Alpha platforms at work with an old Fortran compiler that only supports the old standard.

Still looking for a solution :-(.

--Peter

[Peter_Simon]

Hi, tcprince, thanks for responding.

Yes, I'm using the 32 bit Windows 8.0 compiler. Re your comments:

1) I initialized the sum reduction variables on separate lines. I also expanded the line following the !$OMP END PARALLEL DO to be three separate lines.

This did not make a difference.

2) When you say I don't "have COMPLEX" I don't know exactly what you mean. For instance, the reduction variables are declared COMPLEX(TYPE=LONG). Could this be part of the problem? Please note that in my original post I provided a URL where the entire source file (including declarations) can be retrieved. The machine on which I'm compiling and running the code has a pair of Pentium 4 Xeon processors (without hyperthreading). I'm using OpenMP on this short, simple,interior loop as a first try at something simple where I hoped to get immediate success (ha-ha). My intention, after sucessfully parallelizing this loop, was to then try to parallelize insteadthe outer, enclosing loop, where hopefully some performance gain can be achieved, though I assume it will be more difficult to parallelize correctly.

3) Good point. I changed the code IAW with your suggestion. Note that this isn't my code. I'm just trying to get it to run faster on SMP workstations.

Still looking for a solution :-(, but thanks for the input!

--Peter

[Peter_Simon]

I just noticed something; perhaps it will help in identifying the problem. After I changed the code as suggested by tcprince to

HF1 = 0. !pss 7/6/2004 for OMP
HF2 = 0. !pss 7/6/2004 for OMP
HF3 = 0. !pss 7/6/2004 for OMP
!$OMP PARALLEL DO PRIVATE(J_INT1,RK,RK2,RKL,CFAC,CJ1) &
!$OMP & REDUCTION(+:HF1, HF2, HF3)
First_refl_loop : &

...

and ran the thread checker activity, the "red" diagnostic that I quoted in my original post ("Using of a syncrhonization object at ...") is again produced and it still refers to the exact same source line as it did before I made the edit! That is, it refers to the first source line above (the one that starts with "HF1 = ...". This is several lines prior to the parallel section of code! Does this provide a useful clue???

Thanks,

Peter

[ClayB]

Peter -

It seems that your problem has escalated to the point that it would be better served if you report this to the Intel Premier support site. If none of the "obvious" things that have been pointed out by previuos posts, I think you should seek out the professionals that deal with these kinds of thngs on a regular basis. They may have seen a similar situation in the past and be able to tell you what is going on, or they will have more sophisticated tools and contact with developers to iunvestigate your questions and concerns.

Did you sign up for a Premier account when you registered the Intel Thread Checker?

--clay

[Peter_Simon]

OK, Clay, I've submitted a problem report to the Premier website. I thought I should try here first because I assumed I was doing something wrong that would be easy to spot.

Thanks,

Peter