[Omp] data outside parallel region affected by next parallel region

[Neil Summers]

Bronis,

there should be no race conditions on QERN in the first
loop as each thread works on a different element in QERN.
The QERN array has a label I and the loop is over I.

The second loop only reads from QERN so this should not be
changed by parallelizing the loop.
I have tried putting in barrier and flush statements
to make sure that the data is coherent before continuing,
which were implied by the end of the first parallel loop anyway,
but this did not help.

I have asked for a trial copy of the threading tools,
hopefully this might help.
Are these tools the best for debugging parallel codes?

As I don't think its a race condition,

the machine is a dual Athlon server, using the intel v8.1 compiler.

I will see if the threading tools help when they are installed,
Thanks,
Neil

On Wed, 20 Apr 2005, Bronis R. de Supinski wrote:

>
> Neil:
>
> I have not sorted through the logic of your first loop so
> I don't know if this is the issue but one possibility is
> that you could have a race condition on QERN. Since it is
> shared data, if you are not assured that each element is
> written by at most one thread then the behavior you are
> seeing would not be surprising. Changing apparently unrelated
> code will often change the timing, resulting in the bug emerging.
>
> If you have access to it, you might try Intel's Thread Checker,
> a tool that can identify this sort of error.
>
> Anyway, if it isn't an issue like that, then we would need to
> know more about the situation: what machine? what compiler? etc.
>
> Bronis
>
>
> On Tue, 19 Apr 2005, Neil Summers wrote:
>
> > I have this problem in OpenMP and i cant seem
> > to figure out why it is happening.
> > If the second loop is not parallelised,
> > the first loop in the example below is parallelised fine,
> > the required array QERN is same as in a serial run.
> > But if i then parallelise the second loop, QERN is wrong,
> > even when it is printed out before the second loop is
> > parallelised.
> > This behaviour seems very wrong to me.
> > Any help to why this is happening would be greatly appreciated.
> >
> >
> > !$OMP PARALLEL DO
> > !$OMP& FIRSTPRIVATE(VFRAG,VCORE,VOPT,WT,UK,A,B,P,Q,PLEG,
> > !$OMP&              SINRF,SINRC,SINRO,PQ2,AB2)
> > !$OMP& PRIVATE(RR,VO,ABR,PQR,RRR,K,RCR2,R22,RCR,R2,
> > !$OMP&         VF,VC,VS,L1)
> >          DO 50 I=1,NN,MR
> >             RR = (I-1) * H
> >             VO = FFCI(RR*SINRO,VOPT,NLN)
> >             ABR = (A*RR)**2 + (B*R1)**2
> >             PQR = (P*RR)**2 + (Q*R1)**2
> >             RRR  = R1*RR
> >             DO 31 K=1,NNT
> >                RCR2 =     PQR + PQ2*RRR*UK(K)
> >                R22  =     ABR + AB2*RRR*UK(K)
> >                RCR(K) = SQRT(ABS(RCR2)) * SINRC
> > 31             R2(K) = SQRT(ABS(R22)) * SINRF
> >                DO 40 K=1,NNT
> >                    VF = FFCI(R2(K),VFRAG,NLN)
> >                    VC = FFCI(RCR(K),VCORE,NLN)
> >                    VS(0) = (VF + VC - VO) * WT(K)
> >             DO 36 L1=KQ1M,KQ1
> >              QERN(I,L1,0)=QERN(I,L1,0) + VS(0) * PLEG(K,L1)
> > 36          CONTINUE
> > 40         CONTINUE
> > 50      CONTINUE
> >
> >       write(191,*)qern(1,1,0) ! if next loop is parallelised then this
> >                               ! data becomes corrupt :( why ??????
> > !$OMP PARALLEL DO
> > !$OMP& PRIVATE(KNT,KNF,L1,RP,V,I)
> >        DO 60 IK=1,NK
> >            KNT = FPT(1,IK)
> >            KNF = FPT(2,IK)
> >            L1  = FPT(3,IK) + 1
> >         RP = 0.5 * R1 ** (QNF(9,KNT)+1 + QNF(9,KNF)+1)  * RINTP
> >         V = RP * FORML(J,KNT) * FORML(J,KNF)
> >          V = V * SQRT(2.0 * (L1-1) + 1.0)
> >         DO 55 I=1,NN,MR
> >          FORMF(I,LOCF+IK) = FORMF(I,LOCF+IK) +   V * QERN(I,L1,0)
> > 55      CONTINUE
> > 60     CONTINUE
> >
> >
> > _______________________________________________
> > Omp mailing list
> > Omp at openmp.org
> > http://openmp.org/mailman/listinfo/omp_openmp.org
> >
>