FLOAT_VWALK scaling problem

[m.hadfield]

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).

[arango]

Yea, great catch. Thank you for looking and correcting this problem. This bug has been in the code since the beginning. Last week I was at NOAA and heard complains about the vertical position of the floats. This may explain the problem that they observed about the vertical position of the floats.

The vertical random walk for the predictor-corrector scheme assumes that the vertical diffusivity and its gradient remains constant during the corrector step. I think that this is a good assumption. The vertical mixing parametrization in an ocean model has so many assumptions that this should be the less of our worries.

I agree that the factor 1/SQRT(2) is kind of suspicious with the predictor-corrector code. I will think more about this. I already have in my to do list the problem of random walk in shared-memory applications. Random number generation is extremely tricky in parallel. I gave it a try in shared-memory, but I haven't been able to get identical solutions from different partitions. I need to comeback to this. Perhaps, I have to change how the random numbers are generated for the floats. I already created a parallel routine to generate random numbers (white_noise.F) in the adjoint-based algorithms.