IMPORTANT: Corrected parallel bug in float's vertical random walk

[arango]

Finally, I figure out how to correct the shared-memory bug in the floats vertical random walk. I mentioned this problem before. Getting random number sequences in parallel is very tricky. It is very difficult to get identical ROMS solutions in serial and parallel when random numbers are involved, but it is possible.

• Changed the strategy of generating a normally-distributed random number sequence for vertical walk coefficients. A new global variable rwalk is created in mod_floats.F to store random number sequence for floats.

• Changed the initialization handling of out-of-bounds floats. Previously we have in inp_par.F:

           FLT(ng)%Tinfo(ixgrd,nc)=MIN(MAX(0.5_r8,Fx0(i,ng)),  &
       &                           REAL(Lm(ng),r8)+0.5_r8)
           FLT(ng)%Tinfo(iygrd,nc)=MIN(MAX(0.5_r8,Fy0(i,ng)),  &
       &                           REAL(Mm(ng),r8)+0.5_r8)
  

  This limiting is eliminated in inp_par.F and grid_coords.F and now we have:

           FLT(ng)%Tinfo(ixgrd,nc)=Fx0(i,ng)
           FLT(ng)%Tinfo(iygrd,nc)=Fy0(i,ng)
  

• The checking for out-of-bounds initial locations is now done in step_floats.F when the floats are released:

          IF ((Tinfo(ixgrd,l).lt.0.5_r8).or.                            &
     &        (Tinfo(iygrd,l).lt.0.5_r8).or.                            &
     &        (Tinfo(ixgrd,l).gt.REAL(Lm(ng),r8)+0.5_r8).or.            &
     &        (Tinfo(iygrd,l).gt.REAL(Mm(ng),r8)+0.5_r8)) THEN
            bounded(l)=.FALSE.               ! outside application grid
          END IF

This fixes a parallel bug to get identical solutions in serial and distributed-memory. Now the out-of-bounds floats in MPI have the correct FillValue instead of zero value.

• The random number are now computed with the parallel friendly routine gasdev.F. It uses the same efficient routines used to generate random numbers as in the adjoint-based algorithms. The routine nrng.F (file utility.F) is eliminated.

• The random number sequence is only generated in the floats predictor step. This fixes the problem reported by Mark Hadfield in ​src:ticket:472. The 1/SQRT(2)=0.707 factor was due to the two independent random sequences (predictor and corrector steps). Many thanks to John Wilkin for bringing to our attention that if the variance of the random velocity on the predictor step is 1, and this is independent of the random velocity on the corrector step (also 1), then the two random step combined have a variance of only 1/2 with an standard deviation of 0.707.