random numbers with fixed seeds in convective scheme

[hbarbosa]

In subroutine redist_kf() there are many calls to the random number generator function ran3(). Most of these calls, however, are made using a fixed seed to ran3, which means you always get the same answer back.

For instance, the code below is around line 126. It clearly says it is choosing a random position within the cloud, but the number is drawn as rn=ran3(88)... and the result is compared with the threshold "if (rn.le.fmix) then....". By the way it is written it is definitely not random.

Moreover, the code for the ran3() function, inside of the file random.f90 does not look ok.
Parameters are not defined with clear intent(in) or intent(out) declarations, and optional arguments are not identified. Hence, what the function will do when called with just 1 parameter, is compiler dependent (other parameters are automatically saved between calls? what about the call order from different computing nodes??)!

I also don't know why redist_kf() calls the random number generator directly, since a pile of random number are pre-generated by the MPI_ID==0 processor once the program starts. If each MPI node calls independently the random number generator, the result will depend on how fast the code runs in each node (order of calls to ran3() among all nodes).

I don't know how to fix this, but it seems to be a serious bug in the code.

Best regards,
Henrique

========= Sample code, redist_kf.f90, around line 126.
! Simply mix all particles by assigning a random position within cloud
! In this case, backward run is not wroking since this reposition process is not
! reversible.

IF (mix_option .eq. well_mix) then ! Well-mixed

!! only consider updraft (usually >> downdraft flux)
!! Choose a random # evenly distributed in [0,1]

rn=ran3(88)

if (rn .le. fmix) then ! inside cloud

write(*,*)'well mixed, fmix=,rn=',fmix,rn

! --umfzf(j), zf(j)
! --|X- rn2 (particle position)

! --umfzf(j-1),zf(j-1)

rn2=ran3(881)

[jbrioude]

redist_kf has not been changed since the original version of PILT.
What you report looks like bug, and depending on the compiler, it will crash or not.
I don't recommend using the convective scheme for the moment.

[hbarbosa]

Hi Jbrioude,

Ok, good to know as I'm not using convection scheme at this time.

Just a quick question:
You change the status of the Ticket to closed/fixed

But it is not fixed yet right? Will someone still look into this problem if the status is set to "fixed" ?

Best regards,
Henrique

[jbrioude]

I will leave it open until a fix is provided.

[adingwell]

Moved this over to the next milestone, still no fix available.

[pesei]

Ticket retargeted after milestone closed