id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
472	FLOAT_VWALK scaling problem	m.hadfield	arango	"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).

"	bug	closed	major	Release ROMS/TOMS 3.4	Nonlinear	3.4	Fixed		m.hadfield