hello friends, i was just trying to see the performance of different compiler (gfortran and ifort) and there is a problem inthis part of the code: "===============Creating Initial Configuration==============" 58 write(*,& 59 '(1x,"Minimum distance between any two particle is", 1x,f6.4)'),rcut !rcut=1.5 60 !----------------------------------------------- 61 ! INITIALISE POSITION 62 !----------------------------------------------- 63 10 do i=1,ntot 64 x(i)=boxl*(ran(seed)-0.0) 65 y(i)=boxl*(ran(seed)-0.0) 66 z(i)=boxl*(ran(seed)-0.0) 67 call pbc(x,y,z,boxl) 68 end do 69 !- - - - - - - - - - - - - - - - - - - - - - - - 70 ! KEEPING MINIMUM DIST. BETWEEN ANY TWO 71 ! ATOM GREATER THEN RCUT 72 !- - - - - - - - - - - - - - - - - - - - - - - - 73 do i=1,nap-1 74 do j=i+1,nap 75 dx=x(i)-x(j) 76 dy=y(i)-y(j) 77 dz=z(i)-z(j) 78 79 dist=dsqrt(dx*dx+dy*dy+dz*dz) 80 tr=tr+1 81 ! write(*,*) tr 82 if (dist<rcut)go to 10 83 end do 84 end do 85 write(*,'(1x,"Success after",1x,i0,1x,"try")')tr 86 call mindist(x,y,z) 87 write(*,*) & 88 "===========================================================" 89 write(*,*) "" 90 91 !----------------------------------------------- 92 ! INITIAL CONFIGURATION DONE 93 !----------------------------------------------- while compiling with ifort, its converging after 160k steps, but even after waiting for 1000k steps with gfortran, its not converging......do you think its problem with ran? can you suggest a better way?
In article <c28af821-e279-42f8-8b8c-16204ef43...@p25g2000pri.googlegroups.com>, rudra <bnrj.ru...@gmail.com> writes:
> hello friends, > i was just trying to see the performance of different compiler > (gfortran and ifort) and there is a problem inthis part of the code: > "===============Creating Initial Configuration==============" > 58 write(*,& > 59 '(1x,"Minimum distance between any two particle is", > 1x,f6.4)'),rcut !rcut=1.5 > 60 !----------------------------------------------- > 61 ! INITIALISE POSITION > 62 !----------------------------------------------- > 63 10 do i=1,ntot > 64 x(i)=boxl*(ran(seed)-0.0) > 65 y(i)=boxl*(ran(seed)-0.0) > 66 z(i)=boxl*(ran(seed)-0.0)
> 83 end do > 84 end do > 85 write(*,'(1x,"Success after",1x,i0,1x,"try")')tr > 86 call mindist(x,y,z) > 87 write(*,*) & > 88 > "===========================================================" > 89 write(*,*) "" > 90 > 91 !----------------------------------------------- > 92 ! INITIAL CONFIGURATION DONE > 93 !----------------------------------------------- > while compiling with ifort, its converging after 160k steps, but even > after waiting for 1000k steps with gfortran, its not > converging......do you think its problem with ran? can you suggest a > better way?
What is seed? What is boxl()?
program a integer i, seed seed = 0 do i = 1, 4 print *, ran(seed) end do print * seed = 1 do i = 1, 4 print *, ran(seed) end do seed = 42 do i = 1, 4 print *, ran(seed) end do end program a
rudra wrote: > while compiling with ifort, its converging after 160k steps, but even > after waiting for 1000k steps with gfortran, its not > converging......do you think its problem with ran? can you suggest a > better way?
Are you certain that it necessarily will converge? Are you getting the same random sequence from the two compilers?
What have you done to try to characterize the nonconvergence? Do you even have the slightest idea where the two compilers are diverging? I would strongly recommend that you study that, using write statements or a debugger.
In article <91157a9b-7293-4334-b813-5b611fb80...@p25g2000pri.googlegroups.com>, rudra <bnrj.ru...@gmail.com> writes:
> this is a subroutine and seed, boxl is supplied`
Nothing like deleting all context from your follow up. When I asked 'what is seed?', I literally meant give us the value. Did you actually RTFM, which tells you how to use RAN() in gfortran? When I asked 'What is boxl?' Either show us the code or at least tell us what boxl() does.
Craig Powers wrote: > rudra wrote: >> while compiling with ifort, its converging after 160k steps, but even >> after waiting for 1000k steps with gfortran, its not >> converging......do you think its problem with ran? can you suggest a >> better way? > Are you certain that it necessarily will converge? Are you getting the > same random sequence from the two compilers?
I agree. A program could be very sensitive to roundoff such that it doesn't converge or doesn't seem to converge. In some cases, the result can alternate between values differing in the low order but, and so will 'fail to converge' if compared for equality.
If it diverges (goes to infinity) then that is very different.
When using something like Newton-Raphson, it is non unusual that the limit, even for a scalar, has a period greater than one. For multi-dimensional systems the result can be much more complicated.
Since the OP didn't give many details, it is hard to know, but it might be that on one system it does converge to a fixed point (period one cycle), and on others it doesn't.
> When using something like Newton-Raphson, it is non > unusual that the limit, even for a scalar, has a > period greater than one. For multi-dimensional systems > the result can be much more complicated.
> Since the OP didn't give many details, it is hard to know, > but it might be that on one system it does converge to > a fixed point (period one cycle), and on others it doesn't.
It looks like it's just trying to initialize a particle simulation keeping a minimum distance between particles using periodic boundary conditions. That's something where the ease of converging it is going to depend on the particle density. If it needs 100k steps to succeed on ifort, it may be dense enough that it's difficult to find a good configuration, and the problem isn't due to one compiler or another but rather just that the random sequences aren't the same (which comes back to my question about whether the OP is certain that the random sequences are the same, and what's been done to characterize the divergence between the two compilers).
(Incidentally, that also suggests that it may be appropriate to find another way to create an initial configuration... e.g. start out with some sort of regular configuration and evolve it.)
I didn't even really look at the code in any detail initially, because the basic steps to dealing with the problem are independent of the details of the code. I will note, however, that if performance is any concern, the OP should *definitely* be comparing distsq to rcutsq instead of dist to rcut, as the sqrt taken to get dist will be very expensive and rcutsq can be precomputed.
Oh, and one other thought... you shouldn't need to be doing PBC on your initial positions. Fix your random assignments so that they land in the box correctly.
Actually, a third thought... any particular reason why you do the entire configuration at once and throw the whole thing out if there's an incursion? You could also build it up incrementally, redoing an individual particle if it's inside rcut.
In article <g0adps$9t...@registered.motzarella.org>, Craig Powers <eni...@hal-pc.org> wrote:
>Actually, a third thought... any particular reason why you do the entire >configuration at once and throw the whole thing out if there's an >incursion? You could also build it up incrementally, redoing an >individual particle if it's inside rcut.
That would be a much bigger improvement than a few sqrts.
