Changes between Initial Version and Version 2 of Ticket #472


Ignore:
Timestamp:
11/17/10 04:56:30 (14 years ago)
Author:
arango
Comment:

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.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #472

    • Property Cc m.hadfield added
    • Property Resolution → Fixed
    • Property Status new → closed

  • Ticket #472 – Description

    initial v2  
    1 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.
     1There are a couple of significant problems with the operation of the '''FLOAT_VWALK''' option:
     2  '''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''';
    23
    3 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).
     4  '''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.
    45
    5 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.
     6I 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).
    67
    7 I have applied the correct (I think) scaling in a copy of interp_floats.F on my branch on the developers' repository
     8The 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'''.
     9
     10I have applied the correct (I think) scaling in a copy of '''interp_floats.F''' on my branch on the developers' repository
    811
    912https://www.myroms.org/svn/omlab/branches/hadfield/trunk/ROMS/Nonlinear/interp_floats.F
    1013
    11 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).
     14I 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).
    1215