Custom Query (986 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (373 - 375 of 986)

Ticket Owner Reporter Resolution Summary
#472 arango m.hadfield Fixed FLOAT_VWALK scaling problem
Description

There are a couple of significant problems with the operation of the FLOAT_VWALK option:

1) the nudging velocity that forces the vertical random walk is not scaled correctly before it is applied in interp_floats, leading to the vertical diffusion being too large by a factor equal to the layer thickness, Hz;

2) with this problem fixed, the vertical diffusion applied to the floats is the correct magnitude with VWALK_FORWARD defined, but too small a factor of 0.71 (suspiciously close to 1/sqrt(2)) when the predictor-corrector scheme is in operation.

I investigated these problems with a simple case: fluid at rest with uniform diffusivity at 10-5 m2/s, doubly periodic domain 50 m deep, 5 uniformly spaced levels, 300 floats released at 25 m depth and followed for 0.5 days. The standard deviation of the float vertical position should increase with time as sqrt(2 K t) so at 0.5 days should be 0.93 m. However in the simulation it is 9.3 m (VWALK_FORWARD defined) or 6.6 m (not defined).

The scaling problem arises because the nudging velocity (nudg) is calculated in vwalk_floats.F in m/s and is then applied in interp_floats.F to calculate the rhs term track(izrhs,...) without further scaling. It should be scaled by the layer depth Hz.

I have applied the correct (I think) scaling in a copy of interp_floats.F on my branch on the developers' repository

https://www.myroms.org/svn/omlab/branches/hadfield/trunk/ROMS/Nonlinear/interp_floats.F

I haven't yet looked into the situation where VWALK_FORWARD is undefined, but presumably it arises from the predictor-corrector scheme trying to cope with impulsive perturbations and can be fixed by multiplying the perturbations by sqrt(2).

#473 arango arango Fixed Corrected couple of bugs and typos
Description

Several typos and bugs have been reported in the forum:

  • Corrected misplaced END IF in routine set_avg.F. Many thanks to Hugo Bastos for reporting this typo.
  • Added missing code in def_avg.F needed when restarting and writing time-averaged squared tracer. Many thanks to Wang Dakui for reporting this problem.
  • Corrected problem when writing EcoSim logical switches into NetCDF files. They are now written as integers. I missed these switches when I changed all the logical flags in the I/O NetCDF files. Many thanks to Dmitry Tokarev for reporting this problem.
  • Corrected typo in checkdefs.F when reporting CPP option UV_SMAGORINSKY. Many thanks to Kate Hedstrom for reporting this typo.
#474 arango arango Fixed IMPORTANT: Corrected parallel bug in float's vertical random walk
Description

Finally, I figured out how to correct the shared-memory bug in the floats vertical random walk. I mentioned this problem before in src:ticket:472. 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 random vertical walk velocity. A new global variable rwalk is created in mod_floats.F to store random number sequences for floats. This fixed the shared-memory bug when generating the random numbers.
  • 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 when comparing trajectoris in serial and distributed-memory. Now the out-of-bounds floats in MPI solutions have the correct FillValue instead of a zero value.

  • The random numbers are now computed with the parallel friendly routine gasdev.F. It uses the same efficient routines used to generate random numbers 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: 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.
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.