FLOAT_VWALK scaling problem

[patrick_drake]

From ticket 472:

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


Yes, we noticed this scaling problem at UCSC and corrected it in our local version of the code, back when the VWALK section was in step_floats.F. But I was thinking it may not be appropriate to use the predictor-corrector scheme at all with the VWALK on. After all, each random kick is, by the definition of "random walk," unrelated to the previous time steps. But one may still want to use predictor-corrector for the advective vertical velocity of the floats. It might be best to separate the random and non-random motions more explicitly. Have the advective vertical transport carried out with predictor-corrector in step_floats.F regardless of the VWALK (rather than turning it off with CPP defs), then add in the random part of the motion in FLOAT_VWALK directly, without calling interp_floats and adding the nudging velocity to zrhs. I think this random motion in the nudging is essentially corrupting zrhs from previous time-steps when using predictor-corrector. Even this may not be a good idea, however, as the random motion for a realistic diffusivity can be much larger than the advective motion, and the previous zrhs(s) may be irrevevant.

Becasue of this one could also argue that the predictor-corrector scheme for the horizontal motion should also be turned off when VWALK is on given that a float could easily be kicked into a new current flow regime in a any given time step. For the California Current System, I found that the diffusivity, K, can easily be as high as ~10^-1 m^2/s within ROMS. In a typical ROMS time step of a few minutes, this can easily kick the float a few meters (from dz=(2Kt)^0.5). This could put it into a new horizontal flow direction. We tried to avoid this by creating a separate time step for the floats that was much smaller than the model dt, with a loop inside step_floats.

[m.hadfield]

But I was thinking it may not be appropriate to use the predictor-corrector scheme at all with the VWALK on. After all, each random kick is, by the definition of "random walk," unrelated to the previous time steps.

Indeed. This was why, when I first wrote the FLOAT_VWALK code many years ago, I used forward time steps. The combination of the vertical walk with the predictor-corrector scheme is only a few months old.

Your point about floats jumping too far in one time step is a good one, and using a smaller time step for the floats is a sensible solution.

Incidentally, the scaling bug described in the ticket has been there from the beginning, as far as I know.