Custom Query (986 matches)

The 4DVar data assimilation algorithms have now a fully working balance operator. This can be activated with option BALANCE_OPERATOR. The algorithm follows the methodology of Weaver et al. (2005). The balance operator is used in 4DVar data assimilation algorithms to constraint the error covariance. It is a multivariate approach to estimate the off-diagonal terms of the error covariance matrix. This allows the unobserved state variables information to be extracted from directly observed quantities. The ocean state vector is split between balanced and unbalanced components, except for temperature which is used as the starting point to estimate the balanced part of the other variables. The multivariate formulation is obtained by establishing linear balance relationships between temperature and other state variables using T-S empirical formulas, the linear equation of state, hydrostatic balance, and geostrophic balance.

The balanced free-surface increment can be computed by solving an elliptical equation as in Fukomuri et al. (1998). This can be activated with option ZETA_ELLIPTIC. Otherwise, a it may computed from the hydrostatic balance.

This is a very difficult and complex algorithm. Specially the solution of the elliptic equation with the biconjugate gradient algorithm. We needed the tangent linear and adjoint versions of the biconjugate gradient algorithm. This was very very tricky... Many thanks to Andy Moore for coding and testing this difficult algorithm. We cannot follow the adjoint recipe roules here since the biconjugate gradient method operate on the transpose matrix.

This is the last major peice of ROMS 4DVar data assimilation algorithms. It has been a very torturous and difficult path that took several years and lot of patience. Many thanks to the ROMS adjoint group for their great help and to ONR for funding us to develop these algorithms. Again, many thanks to Andy Moore for his unvaluable cooperation... Also many thanks to Anthony Weaver for his work and advice.

Some of the tracer advection alogorithms are highly nonlinear and may become unstable when running the tangent linear, representer, and adjoint models. This may affect the convergence of the 4DVar data assimilation algorithms. Therefore, it is possible to choose a simpler (less nonlinear) horizontal and vertical tracer advection scheme, if so desired, for the tangent linear, representer and adjoint models. Notice that this strategy still allows us to use highly nonlinear tracer advection schemes in the basic state upon which the tangent linear and adjoint models are linearized. Also, it allows us to use those schemes that have not been adjointed yet, for example, TS_MPDATA. Recall that basic state trajectory is computed by running the nonlinear model.

The flags below are optional. By default, the same options choosed for the nonlinear model are selected for the tangent linear representer, and adjoint models. However, you have the choice to specify different tracer advection options than the basic state.

• TS_A4HADVECTION_TL: use if 4th-order Akima horizontal advection
• TS_C2HADVECTION_TL: use if 2nd-order centered horizontal advection
• TS_C4HADVECTION_TL: use if 4th-order centered horizontal advection
• TS_U3HADVECTION_TL: use if 3rd-order upstream horiz. advection

• TS_A4VADVECTION_TL: use if 4th-order Akima vertical advection
• TS_C2VADVECTION_TL: use if 2nd-order centered vertical advection
• TS_C4VADVECTION_TL: use if 4th-order centered vertical advection
• TS_SVADVECTION_TL: use if splines vertical advection

Many thanks to Brian Powell for suggesting this strategy.

Corrected the release of new floats. The floats were released twice during two consecutive time steps. The conditional for release needs to be:

       HalfDT=0.5_r8*dt(ng)
       DO l=Lstr,Lend
         IF (.not.bounded(l).and.                                        &
      &      (time(ng)-HalfDT.le.Tinfo(itstr,l).and.                     &
      &       time(ng)+HalfDT.gt.Tinfo(itstr,l))) THEN
           ...
         END IF
       END DO

Previously, we have a dt(ng) instead of HalfDT. This triggered the consecutive release.

To facilitate error tracking the routine interp_floats is now inside of a module. So the arguments to this routine were changed to follow modules rules.

Also corrected a major parallel bug in the vertical random walk. We have been hunting for this bug for days. It was very frustrating since the bug desappeared several times. Well, after all this was a random process. Anyway, the major parallel bug was actually in step3d_t.F when computing the vertical diffusivity gradient. Rats..., I have been looking at the drifters routines for days instead. This one was nasty, it has been in ROMS since its implementation!

The float's vertical random walk is now computed in a separated new module, vwalk_floats.F. This facilitated the predictor/corrector for the float vertical position. It is assumed that the vertical diffusivity and its gradient remains constant during the corrector step. The correction is done only in the float spatial positions. The old forward step is still possible by activating new option VWALK_FORWARD.