Page 1 of 2

Parallelism issue in uselrc

Posted: Wed Apr 13, 2011 3:40 pm
by Alexandre Lebouvier
Hello,

I am using special physics electric arcs in Saturne V2-rc2. I try to use the restriking model.

I get some troubles with parallelism when I want to get the restriking position point. My code is working in a single processor, but it does not give me the good position in multi-processors, probably because of the local variable emax.

Here is the code :

      do iel = 1, ncel
       if(xyzcen(3,iel) .gt. 2.d-3 .and. xyzcen(3,iel) .lt. 70.d-3) then
          xelec = propce(iel,ipcdc1)/propce(iel,ipcsig)
          yelec = propce(iel,ipcdc2)/propce(iel,ipcsig)
          zelec = propce(iel,ipcdc3)/propce(iel,ipcsig)

          w1(iel) = sqrt ( xelec**2 + yelec**2 + zelec**2 )

          amex =  min(amex,w1(iel))
          aiex =  max(aiex,w1(iel))
        endif
      enddo
 
      if(irangp.ge.0) then
        call parmin (amex)
        call parmax (aiex)
      endif
 
      if(aiex .ge. econs) then
        iclaq = 1
        ntdcla = ntcabs
        do iel = 1, ncel
          if(w1(iel).gt.emax) then
            xclaq =  xyzcen(1,iel)
            yclaq =  xyzcen(2,iel)
            zclaq =  xyzcen(3,iel)
            emax = w1(iel)
          endif
        enddo

I tried some modifications but I get floating point exception. How can i overcome this parallelism issue ?

Thanks

Re: Parallelism issue in uselrc

Posted: Wed Apr 13, 2011 3:55 pm
by Mickael Hassanaly
Hello,
 
Could you send the complete routine?
 
Mickaël Hassanaly

Re: Parallelism issue in uselrc

Posted: Wed Apr 13, 2011 4:04 pm
by Alexandre Lebouvier
The complete routine is attached to this post.

Re: Parallelism issue in uselrc

Posted: Wed Apr 13, 2011 6:14 pm
by Mickael Hassanaly
So far away, i don't see any mistakes. But when you do "write(nfecra,*) 'xclaq', xclaq, yclaq,zclaq,ntdcla", all processors  are able to write in the listing. So i think you have to either request the N-processor listings to be output or to leave only one processor to write into nfecra. First solution to verify my theory is better and if it's correct, you should improve your routine.
 
Mickaël Hassanaly

Re: Parallelism issue in uselrc

Posted: Wed Apr 13, 2011 9:17 pm
by Alexandre Lebouvier
OK, so what is the command for n-processors listings output ?

Re: Parallelism issue in uselrc

Posted: Thu Apr 14, 2011 11:54 am
by Mickael Hassanaly
Hi,
you can either user the GUI and modify the options of the runcase or fill ARG_CS_OUTPUT="--logp 1" in the runcase.
Mickaël

Re: Parallelism issue in uselrc

Posted: Thu Apr 14, 2011 6:09 pm
by Alexandre Lebouvier
OK, I tested it. The values I am interested in (Emax, xclaq, yclaq, zclaq) are on the processor #7, and the listing gave me the values of the first processor.
So, How can I be sure that code_saturne will use thes values instead of the one of processor #1 ? And how to display the good values (the real Emax and corresponding x,y,zclaq) in the main listing ?
 
Alexandre
 

Re: Parallelism issue in uselrc

Posted: Mon Apr 18, 2011 3:47 pm
by Alexandre Lebouvier
I tried the PARCOM subroutine to make the processors communicate with each other, but the calculation seems to block (no error message but stay at same time step for hours).

Is it the good subroutine to use, ans if yes, can I use it like this in a loop :

     if(aiex .ge. econs) then
        iclaq = 1
        ntdcla = ntcabs

       do iel = 1, ncel
          if(w1(iel).gt.emax) then
            xclaq =  xyzcen(1,iel)
            yclaq =  xyzcen(2,iel)
            zclaq =  xyzcen(3,iel)

            emax = w1(iel)

            if(irangp.ge.0) then
              call parcom (emax)
            endif
          endif
     enddo

    write(nfecra,*) 'claquage ', ntcabs, emax

  endif

Re: Parallelism issue in uselrc

Posted: Mon Apr 18, 2011 11:03 pm
by Yvan Fournier
Hello,
PARCOM is a collective synchronization routine, to be called for fields defined on cells, not local 0-d values.
Check in cs_parall.h for function documentation, but PARMAX would be more useful in your case.
And here again, it is a collective function, to be called the same number of times by all ranks, so it should never be called in a loop on cells, but after the loop. If necessary, do a first loop to obtain the maximum, synchronize it with PARMAX, then do a second loop using the global value.
Best regards,
  Yvan

Re: Parallelism issue in uselrc

Posted: Tue Apr 19, 2011 2:59 pm
by Alexandre Lebouvier
Hello, Thanks for the answer. Actually, when I use 2 loops, I get a SIGFPE signal with 8 processors (on processors #3 and #5) but not with a single processor... I have the same pb with 2 processors. Code_saturne seems to catch the good values on processor #7 but crash before using it. I join the files.
 
Alexandre