Hmm, the option
WET_DRY is not supported in any of the adjoint-based algorithms! The reason is that their associated mask variables would become time-dependent, and we need the entire trajectory for stepping backward in time. However, we will need to change the
TLM and
ADM kernels to add the variational calculus extra term to the discrete code because the wetting and drying masks are adjointable. For example,
Code: Select all
If the nonlinear model code is:
x(i,j) = x(i,j) * rmask_wet(i,j)
The tangent linear code is now quadratic:
tl_x(i,j) = x(i,j) * tl_rmask_wet(i,j) + tl_x(i,j) * rmask_wet(i,j)
and the associated adjoint is:
ad_x(i,j) = ad_x(i,j) * rmask_wet(i,j)
ad_rmask_wet(i,j) = ad_rmask_wet(i,j) + x(i,j) * ad_x(i,j)
Notice that the order of the above two statements matter, and we need the forward solution for
x(i,j). Therefore, it is extremely complicated. Here,
tl_rmask_wet and
ad_rmask_wet depend on
tl_zeta,
ad_zeta, and
zeta. It is very complicated
I think that if we use the split 4D-Var scheme (TWO executables), we can run the
FORWARD nonlinear solution with
WET_DRY activated and the
TLM and
ADM kernels in the inner loops with
WET_DRY off. Recall that the forward nonlinear solution is used to linearize the
TLM and
ADM kernels. However, we never test it. In my opinion, wetting and drying don't belong in variational data assimilation. I don't see the point of it. It is highly nonlinear because it depends on the instantaneous free surface. In addition, the wetting and drying code is
NOT differentiable since it is not derived from continuous equations. An engineering approach is used in its implementation.
Therefore, a sound linearization assumption is to turn off
WET_DRY in adjoint-based applications. That is,
x(i,j) * tl_rmask_wet(i,j) is a neglible high-order term.
