Opened 14 years ago

Last modified 14 years ago

#472 closed bug

FLOAT_VWALK scaling problem — at Initial Version

Reported by: m.hadfield Owned by: arango
Priority: major Milestone: Release ROMS/TOMS 3.4
Component: Nonlinear Version: 3.4
Keywords: Cc: m.hadfield

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

Change History (0)

Note: See TracTickets for help on using tickets.